mesa: refactor and QoL improvements #7042
Merged
Conversation
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
Ideally we will get better ergonomics and better usage of the +abet pattern by focusing (see +ev-foco:mesa) always on a %known peer in the |mesa core, and updating it in the global state in the ev-abet arm. Only the request-maker arms (make-peek/poke) don't use this pattern due to the way attestation proofs for comets are handled. (note: compiles but untested)
(new %turf pill included)
(turf-pill.pill is outdated with ames.hoon but there is a problem booting from a pill that contains the latest kernel, so we need to |commit manually after booting)
if we are in the middle of sending a message, assemble fragments will crash since for any acked fragment it has been removed from the queue. this will cancel the migration for both sender (when acked) and receiver of the ahoy plea. - for the sender, the ahoy plea when resent, will always be acked by the receiver if they succesfully migrated us, and hearing ack will trigger the migration. - for the receiver, if they are sending or receiving anything, they will nack the ahoy plea and cancel the migration. (note: better not to crash on the receiver of the ahoy plea and use retry-pump metrics for the retries?)
The use case for this task is eagerly sending %acks without waiting for the sender of the %poke to retry. (TODO: currently we don't dissallow non-ack payloads (i.e. bigger than bloq=13 fragment), or other vanes to use this task)
This also fixes an issue in |ames where %chum remote scry requests to %alien peers where never triggered once the peer got converted into %known after learning its public key. (TODO) A migration would be needed to go over everything that, although very unlikely, could remain in chums.todos.alien-state and corvert those into actual requests.
Here we also remove the hardcoding of the unix-duct. Because we need a unix-duct to send gifts to the driver, we need to handle that we are still waiting for it in several ways. - For incoming packets ?(%heer %hear) we just no-op since the sender will retry - For timers (/pump, and /fine) we reset them. - For dead-flow and |mesa retry timers, we set them again without sending them - For gifts, like %turf and %public-keys, we set a timer to ask %jael again - For ad-hoc tasks like %tame or %dear we no-op TODO: test the several scenarios handled here: - queued-events in larval stage from previous migrations—might not be so easy - restarts of the driver, delaying the %born task to test the different code paths - general test of the larval stage exit flow—test with -I <jammed_event> and -A <base_desk_with_new_ames_state_migration>
Previously we were no-oping if the message was older than the migration line but this could mean that (n)acks that got lost for could make the flow get stuck. The solution is to always check if we have state for naxplanation messages and if so produce the ack. In the migration we were already binding the live naxplanation on our namespace so we need to look there first. In the case of %acks, can we guarantee that line.state was an ack? In theory we can't guarantee it just by looking at the state of the flow, but, if it was a %nack we would have state in nax.state for live naxplanations and if the naxplanation had suceeded then they are not going to resend the payload anymore. if line.state was an %ack but it got lost we can not know for sure, but, because we were not removing the correct message from nax.sink it's very likely that if line.state is not in nax.state that's because it was indeed a %nack.
The scry endpoint always gives the first lane in the list as the sponsor for the ship—it'd be better to change that to be a cell of [sponsor=@p (list lane:pact:ames)
This restores the behaviour currently present in |ames
(note: also changes the %mess-response gift to be %sage)
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.
++ev-make-messthough...dud=(unit goof)support in %heer/%mess arms'ack'