The tile shows the status pill, who signed and when, who counter-signed and when, and buttons to View, Counter-Sign (admins, when due) and Send to Customer (fully executed only). Finding the contract uses a three-tier lookup run concurrently, and stamps the project id onto the contract when it resolves through the fallback.
Also called: contract on the job · project agreement tile · no contract for this project yet
- 1Tier 1: contracts.project_id equals the project.
- 2Tier 2: an explicitly passed estimate link id.
- 3Tier 3: resolve the estimate link that birthed the project, then fetch that link's contract.
- 4All three run concurrently and the winner is picked by priority.
- 5On a tier-3 hit the contract's project_id is stamped so later loads short-circuit at tier 1.
Two comments, both about real failures. The lookup: 'Customers sign contracts before the project row exists, so contracts.project_id is often null even after the project is created… Without the third tier, the admin's project-management view found nothing for those contracts and rendered "No contract for this project yet" right after the customer had clearly signed it.' And the concurrency fix: 'These were sequential awaits, so a project whose contract is only reachable through tier 3 paid FOUR serial round trips before anything rendered… and the tile sat blank the whole time. Worst case goes from four round trips to two.'
- Contracts invisible on projects created after signing
- A blank tile while four sequential lookups ran
- Contracts permanently unlinked from their project
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →