You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 869c9fa
Browse filesBrowse the repository at this point in the historyBrowse files
Apply the bot reviews of the slashing-protection interchange's second round. An export lists a key once however many times it is requested: a DELETE naming one key twice answered deleted then not_active and handed over an interchange naming it twice, which this client's own record reader refuses, and a repeated --pubkeys did the same. The CLI import parses its file once, staging it before the record is opened for the chain it names, so interchange_chain is gone and StagedHistory exposes its root. The keymanager import parses the interchange on the blocking pool, since a complete-format file runs to tens of megabytes and the handler's thread also drives the duty services. absorb warns when a registered key already has a record and brought no history, since that record is what this client last signed with the key and says nothing about what it signed elsewhere since. The DELETE comments say why the export may run after the keys leave the store (the duty services record before taking the store's read lock) and that a failed export leaves the deletions in place with their records kept for a retry. The interchange_vectors target drops an unused import that failed make lint, and the workflow's by-name clippy step now names the target as the Makefile does, which is why CI had not caught it. Four tests: an import raises an existing watermark and the raise survives a restart, an export lists a key requested twice once, a DELETE listing a key twice exports it once, and history naming a key outside the request gives it a record that a later DELETE answers not_active with. The CLI reference no longer says a failed import leaves a lock file, since the lock is now on the directory.
|`import <file>`| Merges a version 5 interchange, complete or minimal, into the record. Each validator is reduced to its highest slot, source and target and merged by maximum, so nothing already recorded is lowered and slashable data in the file is absorbed rather than refused. All or nothing. With no record yet, the import creates one for the interchange's chain, and a failed import creates nothing but the lock file; the client refuses the record at its next start if that is not its beacon node's chain |
473
+
|`import <file>`| Merges a version 5 interchange, complete or minimal, into the record. Each validator is reduced to its highest slot, source and target and merged by maximum, so nothing already recorded is lowered and slashable data in the file is absorbed rather than refused. All or nothing. With no record yet, the import creates one for the interchange's chain, and a failed import creates nothing; the client refuses the record at its next start if that is not its beacon node's chain |
474
474
|`export [--pubkeys ...] <file>`| Writes the record, or the named validators' part of it, as a minimal version 5 interchange, readable by its owner only. A named validator with no record fails the export, so a typo or the wrong directory cannot produce a file that reads as complete. Takes the record's lock, so the directory must be writable. Refuses to overwrite an existing file |
0 commit comments