Conversation
…n the background, and fix round 6's deploy rough edges - A live call reaches the database once before the worker has it: the entry's limits and the run's birth are one call (weft_start_execution, weft_admit), and the rows every call read (a tenant's routes, the install's domains, a project's worker settings, its infra status) are held in each dispatcher's memory and dropped when Postgres announces a change. A refusal is made on the rows themselves, and nothing is kept while the listening connection is down. - Every birth (live calls, fires, manual runs, setups) is one round trip, and the journal lock and the dedup lock are each spelled once, in SQL. - A worker's journal writes go out in the background, in order; the run waits for them only before it reads its journal, hands something to the dispatcher (a task, a tag, a stop) or ends. A part of a write that never reached the broker is sent again for up to a minute; any other failure stops the run at once. Cost records stay off the run's order. - The token-guessing bound costs a good live caller nothing and still answers a blocked address 429 whatever the gate said. - The broker reads a claimed execution's scope while it claims it, and the database node asks for its endpoints and its connection together. - A hosted frontend gets no token until its deploy workflow puts its first one in place; `target export` says an old token keeps working only when there is one. - `weft status` names the version each trigger fires; `weft tree`, `weft events` and `weft logs` print UTC; `weft tree` says what started a run; the workflow template pins ubuntu-24.04.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes
A live call reaches the database once before the worker has it.
weft_start_execution,weft_admit).Every birth is one round trip. Live calls, fires, manual runs and setups all go through the same SQL function. The journal lock and the dedup lock are each spelled once, in SQL.
Worker journal writes go out in the background, in order.
Token guessing. The bound costs a good live caller nothing, and a blocked address still gets 429 whatever the gate said.
Smaller items (Tangle round 6):
weft target exportonly says an old token keeps working when there is one.weft statusnames the version each trigger fires.weft tree,weft eventsandweft logsprint UTC.weft treesays what started a run.ubuntu-24.04.Schema
There is one released migration per changed group, written with
./setup.sh --migration live_call_one_round_trip --release:entry_rateexec_eventinfra_nodeprojectproject_frontendtasktrigger_activationTested
schema_agreement, the admission and birth tests, and the change notifications.entry_limitsapi_reply(2)api_authapi_ticketapi_unrecordedpostgresinfrasteer_by_tag::abort_takes_the_asker_down_too