[T3241] FIX: stamp exit communication on send completion (_job_sent)

[Danielgergely]

No description provided.

[gemini-code-assist]

Code Review

This pull request refactors the stamping of exit communications by extracting the configuration retrieval into a helper method and triggering the stamping specifically during job completion (_job_sent) and cancellation. A review comment suggests optimizing _stamp_exit_communications to only update and clean contracts that are actually pending (to_clean), preventing potential overwrites of the exit_communication_sent timestamp on re-sends and avoiding unnecessary database operations.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[greptile-apps]

Confidence Score: 4/5

The change is narrowly scoped to exit communication finalization and appears safe to merge.

The updated behavior aligns stamping with successful send completion while preserving cancellation handling and existing recorded notification dates.

T-Rex Logs

What T-Rex did

• Observed the initial state where base send() stamped exit_communication_sent='NOW-1', flipped pending to False, and called cancel_contract_invoices before any _job_sent completion; the base _job_sent did not stamp.
• Observed after the artifact capture that head send() left sent=False and pending=True, while _job_sent('email') stamped sent='NOW-1', flipped pending=False, and called cancel_contract_invoices once.
• Observed after the artifact capture that cancel() remained stamped sent='NOW-2', flipped pending=False, and cancel_contract_invoices was called once for the exit communication.

_{Ran code and verified through T-Rex}

_{Reviews (5): Last reviewed commit: "FIX: greptile comment No. 10052342..." | Re-trigger Greptile}