Skip to content

Spec 002: the report made in the background, behind its address (R4) - #104

Closed
adamjohnwright wants to merge 4 commits into
mainfrom
spec002/report-async-4
Closed

adamjohnwright wants to merge 4 commits into
mainfrom
spec002/report-async-4

Conversation

@adamjohnwright

Copy link
Copy Markdown
Contributor

Spec 002, research R4's open decision, settled. The user left the choice to us. Replaces #98, #100 and #103, with their reviews' findings fixed.

Why: a report cannot be drawn within the edge's 100 s.

  • Spec 001's T007 measured one diagram with an analysis token at 4.6 s cold, with the render service drawing two at once (18.7 s for the last of eight).
  • So a report's figures alone take about a minute for 25 pathways and two minutes for 50, against the ~40 s left after the gateway's wait.
  • More concurrency doesn't help: the host's processors are the limit (spec 001 T005).

Decision: the report is made in the background, behind today's address.

  • Wait, then answer: a request starts the report, or joins one already being made for the same token and parameters, and waits up to 30 s.
  • Ready: 200 with the PDF, sent only once complete, so FR-203's error answers still hold.
  • Not ready: 202 with Retry-After: 10. A browser gets a small page that asks again by itself; a script following Retry-After gets the PDF.
  • Kept: a finished report is held for one hour (FR-211 amended), and a report is abandoned after 5 minutes.
  • SC-203 becomes the time to a ready PDF:
    • 25 pathways: today's time, or 2 minutes if today's is faster;
    • 50 pathways: 4 minutes.
  • WebsiteAngular's part: the "PDF Result" button opens the address in a tab rather than downloading it, and the gateway passes 202 and Retry-After through.

Alternatives considered (R4): a shorter gateway wait, more concurrency or fewer pathways (none gets under 40 s); streaming the PDF early (breaks FR-203); a new address for the result (breaks people's scripts).

From #98's review:

  • The gateway: its report lane stops queueing report requests, because one lane plus a 30 s wait would serialise every browser's polling.
  • The kept report: held in memory only, checked against the analysis service before it is sent, and dropped on a new release.
  • One error rule; joining requests don't count against the queue; the budget runs from starting.
  • An abandoned request ends only its own wait.
  • Render requests from reports share a cap.
  • The data model gains a Job.
  • Leftovers from the synchronous design are fixed.

From #100's review:

  • Memory: kept reports are capped at 512 MB in all.
  • The printer's working page sits on memory-backed storage, and is cleared at start.
  • The gateway keeps its per-client share for reports and answers 503 if pdf-export is unreachable.
  • The token check is a named call with a timeout.
  • Logs hold a hash of the token, not the token.

From #103's check: FR-210 states the gateway's share and pdf-export's two-per-client limit. The client is named in a header the gateway always overwrites (X-Reactome-Client), not X-Forwarded-For, which a client can forge.

🤖 Generated with Claude Code

adamjohnwright and others added 4 commits November 2, 2026 21:25
Spec 001 T007 measured one diagram with an analysis token at 4.5 s cold, two
drawn at once: a report's figures take about a minute for 25 pathways and two
for 50, against the 40 s the edge's 100 s leaves after the gateway's wait. The
user left the choice to us. The report is now made in the background: a
request starts or joins it and waits up to 30 s, then answers 200 with the PDF
or 202 with Retry-After (a self-refreshing page for a browser); the same
address serves the PDF once ready, and a finished report is kept for an hour.
SC-203 is the time to a ready PDF (25 pathways: today's, or 2 minutes; 50: 4
minutes). The website's button opens the address in a tab; the gateway passes
202 through.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ule, a Job

- The gateway's report lane stops queueing report requests: with pdf-export
  holding a request up to 30 s, a lane of one would serialise every browser's
  polling. pdf-export's own limits protect it.
- A finished report is kept in the service's memory only, never on disk, for an
  hour; the analysis service is asked about the token before a kept report is
  sent (404/410 drop it); all are dropped when the release changes. US4, SC-205,
  the plan's storage and R7 say so.
- One error rule: a report ended by an error answers it to every waiting request
  and the next, then is forgotten. A joining request is never counted against the
  queue (eight by default); the 5-minute budget runs from starting.
- A request abandoned ends only its own wait. Reports' render requests share a
  cap; SC-203 is measured with one report and no other render traffic.
- data-model gains a Job; 202/503 carry no-store and a browser page; the curl
  difference, the quickstart's background runs and the leftovers fixed. Token
  timings updated to T007's checked run (#99).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…irness, the check

- The printer's working HTML, which holds the submitted identifiers, lives on a
  memory-backed filesystem in a private folder, removed when the print ends and
  emptied at start; SC-205 adds a run killed while printing.
- Kept reports are capped at 512 MB in all, oldest dropped first.
- The gateway keeps its per-client share for the report path (refused past it,
  never queued), passes the client on, gains pdf-export as a second upstream, and
  answers 503 when it cannot reach it; pdf-export allows two waiting reports per
  client.
- The token check is named: call 1, on every request, 5 s, its 404/410 passed on,
  anything else 503; the graph's release is read with the species on each request.
- One instance; errors that end a report are FR-203's; the token is logged as a
  hash; the plan's scale line and the gateway notes no longer say one at a time.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…eader that cannot be forged

FR-210 no longer says the gateway passes report requests straight through: it
sends them on unqueued, keeping its PER_CLIENT share, and FR-210 states
pdf-export's own two-per-client limit. The client is named in
X-Reactome-Client, which the gateway always overwrites with its clientOf
(IPv6 by /64); X-Forwarded-For is not used, as nginx appends to what a client
sends. US4's test searches the disk, the printer's memory-backed folder
included.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@adamjohnwright

Copy link
Copy Markdown
Contributor Author

Replaced by the follow-up PR with this check's findings fixed.

adamjohnwright added a commit that referenced this pull request Nov 2, 2026
…105)

Spec 002's R4 settled (the user left it to us). Spec 001 T007 measured one
figure with an analysis token at 4.6 s cold, two drawn at once, so a report's
figures alone take about a minute for 25 pathways and two for 50, past the
edge's 100 s. The report is now made in the background behind today's address:
a request starts or joins it and waits up to 30 s, then answers 200 with the
PDF or 202 with Retry-After (a page that asks again, for a browser). A finished
report is kept in memory only, at most 512 MB in all, for an hour, checked
against the analysis service before it is sent; the printer's working page is
on memory-backed storage. The gateway stops queueing report requests, keeps its
per-client share and names the client in a header it always overwrites; the
service's port is reachable only from trusted internal callers. SC-203 is the
time to a ready report. Reviewed through #98-#104.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant