Make async flow logic handle missing client transaction IDs

Per EPP RFC 5730, the <clTRID> element is optional. However, we weren't handling
it not being specified in asynchronous contact/host deletions because we were
adding it directly as a parameter value on a task, which does not allow null and
thus threw a NullPointerException.

This fixes handling for nulls (the parameter isn't set at all) and adds a test.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=194123259
This commit is contained in:
mcilwain 2018-04-24 12:01:05 -07:00 committed by jianglai
parent f56355c9e8
commit 33505f4df7
16 changed files with 196 additions and 47 deletions

View file

@ -65,7 +65,26 @@ public class ContactDeleteFlowTest
assertAboutContacts().that(deletedContact).hasStatusValue(StatusValue.PENDING_DELETE);
assertAsyncDeletionTaskEnqueued(
deletedContact, "TheRegistrar", Trid.create("ABC-12345", "server-trid"), false);
assertAboutContacts().that(deletedContact)
assertAboutContacts()
.that(deletedContact)
.hasOnlyOneHistoryEntryWhich()
.hasType(HistoryEntry.Type.CONTACT_PENDING_DELETE);
assertNoBillingEvents();
}
@Test
public void testSuccess_clTridNotSpecified() throws Exception {
setEppInput("contact_delete_no_cltrid.xml");
persistActiveContact(getUniqueIdFromCommand());
clock.advanceOneMilli();
assertTransactionalFlow(true);
runFlowAssertResponse(loadFile("contact_delete_response_no_cltrid.xml"));
ContactResource deletedContact = reloadResourceByForeignKey();
assertAboutContacts().that(deletedContact).hasStatusValue(StatusValue.PENDING_DELETE);
assertAsyncDeletionTaskEnqueued(
deletedContact, "TheRegistrar", Trid.create(null, "server-trid"), false);
assertAboutContacts()
.that(deletedContact)
.hasOnlyOneHistoryEntryWhich()
.hasType(HistoryEntry.Type.CONTACT_PENDING_DELETE);
assertNoBillingEvents();