Tracing a misleading reCAPTCHA error to partial registration
A customer record existed despite the reCAPTCHA error. I traced the real failure to environment configuration and stopped a rollback that could corrupt successful work.
Disclosure: Client and internal project details have been anonymized.
Overview
New-account registration appeared to fail with an “unable to verify request” message. Retrying with the same email then produced “account already exists.”
The visible error resembled a reCAPTCHA failure, but I treated the persisted customer as stronger evidence than the message in the browser. That moved the investigation past request verification and into the later provisioning steps.
Backend logs and code tracing revealed several environment-specific configuration mismatches during company-account creation. The same evidence exposed a deeper risk: registration saved the customer before the rest of provisioning finished, with no transaction covering the full sequence.
The investigation traced the failure to environment configuration, identified two confirmed role mismatches, and ruled out automatic rollback because it could delete successful work after an ambiguous timeout.
The challenge
Registration crossed several systems. The backend validated the request, created a commercetools customer, created a company account called a business unit, assigned roles and stores, and initiated verification email delivery.
The frontend presented this as one operation, but the backend committed each step separately. Customer creation finished before business-unit provisioning, so a retry found the email already in use.
Once customer creation succeeded, any later failure left a partial account behind. The browser described the request as unsuccessful even though the system had accepted part of it.
That mismatch made the defect difficult to interpret and turned every retry into another symptom.
Following the persisted side effect
The existing customer record was the decisive clue.
Observed request sequence
reCAPTCHA validation ran before customer creation. If that check had rejected the request, no customer would have been saved. The existing record showed that registration had passed validation and failed later.
Backend logs and code inspection placed the failure in business-unit creation. Required roles were either unusable or missing in the target environments, and a configured production store did not exist.
The system exposed these problems one at a time as raw commercetools errors. Fixing one reference allowed registration to continue until it reached the next mismatch.
Verification
Backend logs, code order, and the customer record established that request verification had already passed before business-unit creation failed. Comparing referenced roles and stores with each target environment then exposed the configuration drift one dependency at a time.
Real confirmation responses validated the confirmation-page fix, while unit tests covered success, consumed-token, genuine-error, reworded-404, and server-error branches.
The original incident record confirms the role corrections but not the final store-key edit, so the result is scoped to the changes the evidence supports. The investigation also established a stronger release practice: validate environment-specific object references as one set rather than discovering each mismatch through customer registration.
Outcome
The investigation replaced the reCAPTCHA theory with a root cause that connected configuration drift to the partial registration. Correcting two role mismatches addressed the confirmed environment drift, and the unsafe rollback did not ship. That protected successful downstream accounts from being left with references to a customer the storefront had deleted.
The result was both diagnostic and preventive: it separated live configuration repairs from application defects and established that persisted state—not the generic browser message—defined the safe recovery boundary.