Expand description
bynk dev --ready-json <FILE> (#2138, end-to-end testing track §3.5,
DECISION F): a machine-readable readiness signal.
Once every served context has answered an HTTP probe, bynk dev writes
{ "<worker>": "<url>" } to the file. A test runner (bynk test --against dev) or a wrapper such as bynk-lang/bynk-dev waits for the file instead
of looping on a warm-up request. The file is removed when the session starts
(so a stale one is never read as ready) and when it stops.
Readiness means each Worker answers a request. It does not mean the dev-registry Service Bindings between them have connected yet: they converge shortly after start.
Structs§
- Readiness
- The pending readiness of one
bynk devsession: the workers still to answer, and where to write the file once none remain.
Constants§
- SLOW_
NOTE_ AFTER - How long without readiness before
bynk devnotes, once, which contexts haven’t answered.
Functions§
- probe
- Whether something answering HTTP listens at
host:port. Sends aHEAD /(safe per RFC 9110, so aGET /route with side effects is never tripped) and takes anyHTTP/status line as an answer, a 404 included: every emitted Worker has afetch, so any status means it is up. - ready_
json - The readiness file’s contents: each worker’s URL, by worker name.
- remove
- Remove
pathif it is there. - unprobeable
- Why the wrangler passthrough
argsserve somewhere the readiness probe (plain HTTP on localhost) can’t reach:-- --local-protocol https, or-- --ipbound to an address that isn’t loopback. - write_
atomically - Write
contentstopathatomically: to a sibling temporary file first, then renamed overpath, so a reader never sees a half-written file.