[P2] Interpreter: discarded Promise.then rejection exits successfully

Open
  • Is something wrong?
#3,464 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
15/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp, typescript
Domain
compilers

Research direction

Start with the one-line repro Promise.resolve(1).then(()=>structuredClone(()=>{}));, which should exit 1 with a DataCloneError but currently exits 0 silently. The baseline and proof.json files under artifacts/p2-work/unhandled-async-rejection-3456 show the expected diagnostic. The issue is scoped to the interpreter's handling of discarded reaction rejections and warns against changing the compiler files, so confirm the scope with the maintainer first. Done means the repro reports the guest reason by default while handled and caught cases, custom capability policy and idle exit behave as before.

Written by the indexing model from the issue text.

Description

bug priority: P2

A rejected result of a supported Promise.then reaction can disappear in the interpreter: execution exits successfully without any diagnostic.

Promise.resolve(1).then(()=>structuredClone(()=>{}));

Strict TypeScript accepts the unchanged source. Node22 exits1 with DataCloneError. Immutable1aa/Core1693 interpretation exits0 with empty stdout/stderr. The exact same failure persists with a complete hash-checked copy of the qualified #3453 nominal error-transport build (Core8EBED1CD06CACD2FD9D1034904A713A208362CDEE27FD15825BC24E4832FD03B): natural exit0, empty output.

This report is scoped to missing default failure reporting for this exact discarded reaction; it does not assume that every reaction producer fails. #3453 fixes caught nominal error values, #3459 separately tracks an already registered rejection listener being bypassed by implicit top-level waiting, and #3456 owns the compiled missing-observation path. Closed #228 covered async callbacks invoked by built-ins; closed #195 covered reaction callback routing/species; closed #3225 concerns compiled pending-promise liveness. All-state unhandled/reaction/then searches found no focused open interpreter owner. Existing broad roadmaps remain outside this repair.

A supported failing async operation must not silently appear successful. Preserve exact guest reasons, handled/caught outcomes, custom capability policy, never-settling idle exit and event-loop scheduling. No deadline/retry/skip or expected-output relaxation is justified.

Exact source SHA256:7239AE05A1E191579C4F840354E5533DDC1A758F6741676DE2E176AF12F79521.
Baseline evidence: artifacts/p2-work/unhandled-async-rejection-3456/baseline-1aa-v1/unhandled-reaction and proof.json.
Post-transport persistence proof: artifacts/p2-work/top-level-promise-rejection-listener-review/reaction-persistence-qualified3453-v1/proof.json, SHA256:7C20EAFDB1ADDE53A4A144F61467F2AECD3CB1350FD3E571F168C747BFD28E44.
Profile: --no-tsconfig --lib es2022,dom. All23 qualified owner/copied compiler files remained byte-identical before/after; no Source edits or forced termination were used. Compiled semantic behavior is owned separately by #3456; no interpreter acceptance is claimed from its controls.

Dominant language
C#
Stars
156
Forks
4
Avg merge
13h 33m
Merged PRs (30d)
45

Getting set up

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 nickna/SharpTS

All issues in nickna/SharpTS

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.