@sohambasu963draftchecks…fix/docusign-account-id-populate → master1 files · +21 −6updated 8h agoAccount-scoped DocuSign tools fail with the opaque error 'account_id' while OAuth and non-account-scoped tools work — reproducible on a DocuSign demo account, and explicitly passing accountId (either casing) doesn't help.
Plain: DocuSign demo account: account-scoped tools fail with KeyError 'account_id' — customer provided log_LF-kqhDhNzh5 / log_bHo3gLhR3iqd, waiting ~5 days.
_populate_request_fields unconditionally overwrote request.accountId/account_id with the metadata-resolved value — directly contradicting the userId auto-population three lines below, which populates only when the field is unset. Account fields now follow the same only-when-missing rule. This alone unblocks the customer (their explicit ID stops being clobbered by whatever the broken resolution produced).get_base_url used data['accounts'][0]['account_id'] raw dict access; a userinfo account entry missing the key surfaced to customers as the literal string 'account_id'. Now raises a ValueError naming the missing keys and suggesting the fix.These two fixes are verifiable from the code and address the reported symptoms, but I could not reproduce the demo-account userinfo response locally — there may be an additional demo-environment quirk in get_base_url's fetch/fallback chain (the function has extensive placeholder_account_id fallback logic worth a deeper look). If the customer still fails after this, the new error message will say exactly why.
py_compile passes. Behavior change is conservative: auto-population still happens whenever the field is empty (the only previous working path), and explicit values — previously impossible to use — now take precedence.
🤖 Generated with Claude Code