feat(std/web): Middleware, Next, WebApp, the web builder and app.answer #777
No reviewers
Labels
No labels
loop
queue/failed
queue/queued
ready
status/parked
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
torbscript/language!777
Loading…
Reference in a new issue
No description provided.
Delete branch "loop/776-web-middleware-app"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Refs #94, #776.
Commit 1 adds
Middleware,Nextand the probe of docs/design/WEB.md section 8 (tests/conformance/web-next-record-capture). Probe outcome: a record carrying a function value with invisible captures crosses into a task; the probe is green under JavaScript and PHP conformance in CI and printshello /api/orders. SoNext.endpointstays aHandler. Commit 2 addsWebApp,web { },answerand thestd/httpadapter. Commit 3 fixes the tier A gates (formatting, generated docs and skill pages, self-contained doc examples, loopback test usesawait()/result()in a task top level).Middleware,Next,WebApp, theweb { }builder andapp.answer(step 2 of #94) #776Middleware,Next,WebApp, theweb { }builder andapp.answer(step 2 of #94) #776Middleware,Next,WebApp, theweb { }builder andapp.answer(step 2 of #94) #776c5e4b1d: tier A (linux-x64) failedCI red on
c5e4b1d:ci / tier A (linux-x64)failed after 11m29s, andci / gatesfailed with it. Every other check is green, including the JavaScript and PHP conformance runs. I could not read the job log (the log endpoint of the API returned an error for me), so I do not know the cause. It may be the probetests/conformance/web-next-record-capture(the PR body says CI decides whetherNext.endpointstays aHandler) orstd/web/tests/app.test.trb.No review yet; the next CI run on a new head brings me back. When you push the fix, please record the probe outcome in the PR body, as the acceptance criteria of #776 ask.
std/webcore (WEB slice 2) #94std/livepage placement (WEB slice 6) and the client script (slice 7) #103std/livepage placement (WEB slice 6) and the client script (slice 7) #103std/livepage placement (WEB slice 6) and the client script (slice 7) #103CI red on
7f61a96:ci / tier A (linux-x64)failed after 41m43s andci / gatesfailed with it. Every other check that ran is green (bootstrap, JavaScript and PHP conformance, same-C, playground, pdisc, commit messages). I still cannot read the job log through the API (404), so the cause is unknown: likelystd/web/tests/app.test.trbortests/conformance/web-next-record-capture.No review yet; the next CI run on a new head brings me back. With the fix, please also record the probe outcome (does
Next.endpointstay aHandler) in the PR body, replacing the "Work in progress" line, as the acceptance criteria of #776 ask.Review of
e7b46cd4(CI green on this head, incl. JavaScript and PHP conformance and tier A; not a draft; mergeable).Checklist
Next.run,answer,pageOfand the adapter match WEB.md 3.3/3.8/3.9 and the body of #776; the cause stays out of the page (tested).endpoint: Handler"), the status line and slice table are updated, the PR body states the outcome, the skills pages are regenerated.Findings
Trailinstd/web/tests/app.test.trb(the type with the doc comment "writes its name into a shared trail on the way in and on the way out") never records anything:aroundjust returnsnext.run(request).await(), and itsnamefield is unused.stampedtherefore only proves that one header is added. As written, wrapping the layers in the reverse order would still pass every test, so the one behavior thewrapdoc comment promises ("the firstwrapis the outermost") is unpinned. Make the order observable without shared mutable state (a layer cannot share avaracross the task boundary), for example two layers that each prepend/append their name to a response header or body on the way out (X-Trail: inner,outerfor outermost first), and a layer that fails or answers differently depending on what the layer above it added to the request. Assert the exact order, and drop or fix the misleading doc comment onTrail.Rewritereplaces the request and the test checks that the handler saw the new path, but nothing checks that a layer aboveRewritestill holds the original request. Add one outer layer that readsrequest.path()afternext.run(...)returns (for example by stamping it into a header) and assert it is the original path. Same test as finding 1 can carry it.Non-blocking
tests/conformance/web-next-record-capture.allocationsholdsunbudgeted: the first run of the probe, the count is read from CI.tests/conformance/README.mdreservesunbudgeted:for programs whose three counts differ; this one is deterministic, so write the number (sh tools/conformance.sh --filter web-next-record-capture --update-budgets, the count is in the CI log of tier A) in this push or a follow-up.WebApp.handlerCount()andtryWebare public additions beyond the three builder members the design of #776 fixes ("the receiver has no other members").handlerCountis visible as a bare name inside everyweb { }block. Consider making it private to the module or computing the check without a public accessor.tryWebis fine for the refusal tests, but it is an extra exported name worth one line in the PR body.WebApp.answerreturnsFailfor an application without a handler, which contradicts "always answersOk" in the doc comment and the docs page; unreachable throughweb, but the sentence should say so or the case should be a panic.e7b46cd47df0e33aa5d5View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.