Fire-and-forget writes escape the per-request transaction (commit even when the handler throws)

Open Beginner friendly
#1,289 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
65/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Quiet
Tech stack
javascript, nodejs, typescript
Domain
backend, databases, documentation

Research direction

Start by reading and running integrationTests/qa-scratch/txn-escape.test.ts to confirm the awaited and fire-and-forget behavior described in the issue. Update the relevant transaction or HTTP handler documentation to state that writes must be awaited to join the request transaction, and that escaped writes survive a handler throw.

Written by the indexing model from the issue text.

Description

area:rest-api documentation

Summary

Only writes that are awaited within an HTTP resource handler join the per-request transaction (atomic + isolated). Work spawned outside the awaited chain — setTimeout, queueMicrotask, or an un-awaited promise — runs after the request transaction has already committed/aborted, so it lands in its own independent immediate transaction. Consequently a fire-and-forget write commits even if the handler later throws and its visible (awaited) work is rolled back, producing an orphan write.

This is consistent with the ALS-scoped "commit on await-resolve" design — awaited work is correctly all-or-nothing and committed state is never corrupted — but it's an undocumented sharp edge.

Repro

Handler issues an awaited write + a setTimeout/un-awaited write, then throws. The awaited write rolls back; the escaped write is committed.
Exploratory test: integrationTests/qa-scratch/txn-escape.test.ts.

Suggestion

Document that writes must be awaited inside a handler to participate in the request transaction; fire-and-forget writes are independent and survive a handler throw. (No code change implied unless we want to detect/warn on escaped writes.)

Found via the exploratory QA campaign (qa-explorer), scenario QA-032. Harper 001bf7b9c (v5.1.0, main).

Dominant language
JavaScript
Stars
89
Forks
10
Avg merge
1d 15h
Merged PRs (30d)
196

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from HarperFast/harper

All issues in HarperFast/harper

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.