mostlyright-data 0.14.1__tar.gz → 0.14.2__tar.gz

{mostlyright_data-0.14.1 → mostlyright_data-0.14.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mostlyright-data
-Version: 0.14.1
+Version: 0.14.2
 Summary: Mostly Right CLI for reproducible, reviewed Parquet datasets
 Project-URL: Homepage, https://mostlyright.md/
 Project-URL: Documentation, https://mostlyright.md/docs/guides/cli/

{mostlyright_data-0.14.1 → mostlyright_data-0.14.2}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "mostlyright-data"
-version = "0.14.1"
+version = "0.14.2"
 description = "Mostly Right CLI for reproducible, reviewed Parquet datasets"
 readme = "README.md"
 requires-python = ">=3.13,<3.14"

{mostlyright_data-0.14.1 → mostlyright_data-0.14.2}/skills/mr-data-build/SKILL.md

@@ -131,10 +131,10 @@ gap rather than doing anything, and `export-hosted-candidate`, which is a backen
 | `mr-data open` | Mint a single-use, short-lived address that continues this session in a browser at one dashboard path, and print it. `--open` hands it to the platform opener. The credential decides who mints: a device credential — what `mr-data login` stores — mints at Cloud, and a personal access token mints at Studio. |
 | `mr-data promote` | Ask Studio to publish one table after a person's decision. The Harness worker does not perform the catch-up or scheduled refresh; report those only when another deployed component returns durable evidence that it did. |
 | `mr-data reschedule` | Change how often one live table refreshes, without the demote and promote that would reset its bookkeeping and buy a catch-up run. `--cadence` takes a cron expression or an interval such as `every 6h`; `--why` records the reasoning. It starts no run. `--lock` freezes the schedule so Studio stops adjusting it; `--unlock` lets it follow the source again. |
-| `mr-data table` | Report what one table is serving and how its refresh schedule is going: the state in plain words, the schedule in force, the next refresh, the schedule that was asked for and the reason given for it, and — once Studio has settled on one — the interval it measured and how many source updates that rests on. `table rename TABLE --name NAME` writes a new name, lowercase snake_case and unique within its dataset, fenced on that dataset's version and retried once if somebody else wrote first; nothing is rebuilt, because every run, version and schedule hangs off the identifier, which does not move. `table archive TABLE --confirm-name NAME` retires the table and frees its name; a live table is refused until you `demote` it, and nothing built is deleted. |
+| `mr-data table` | Report what one table is serving and how its refresh schedule is going: the state in plain words, the schedule in force, the next refresh, the schedule that was asked for and the reason given for it, and — once Studio has settled on one — the interval it measured and how many source updates that rests on. `table rename TABLE --name NAME` writes a new name, lowercase snake_case and unique within its dataset, fenced on that dataset's version and retried once if somebody else wrote first; nothing is rebuilt, because every run, version and schedule hangs off the identifier, which does not move. `table archive TABLE --confirm-name NAME` retires one table you name by the name it is called, and frees that name; a live table is refused until you `demote` it, and nothing built is deleted. `table archive TABLE [TABLE ...] --confirm DELETE` retires as many tables as you name at once: `DELETE` is the literal word, typed exactly, and it confirms the identifiers you typed rather than a name, so each table is retired under the name Studio is holding for it. Every table is attempted whatever the one before it answered, one line is printed for each, and the command exits non-zero if any was not retired — so read the outcome of each rather than the exit code alone. `--confirm-name` is refused when you name more than one table. |
 | `mr-data pin` | Ask Studio to freeze one table pointer on an exact version, for a rollback or a hold. |
 | `mr-data unpin` | Ask Studio to resume pointer tracking; read the returned state before claiming it resumed. |
-| `mr-data demote` | Ask Studio to withdraw the pointer and any schedule it owns. |
+| `mr-data demote` | Ask Studio to withdraw the pointer and any schedule it owns, for one table or for as many as you name: `demote TABLE [TABLE ...]` withdraws them one after another, attempts every one of them whatever the one before it answered, prints a line for each, and exits non-zero if any is still live. Pair it with `table archive` when you are retiring a set: a live table cannot be archived, so it is withdraw-then-archive, two commands rather than a loop. |
 
 `auth`, `login`, `whoami` and `clarify` are the same implementation in both profiles, and
 `clarify` alone reaches nothing at all. The other twenty-four answer from Studio. Eight only
@@ -1259,6 +1259,17 @@ or a hold, `mr-data unpin TABLE_ID` resumes tracking, and `mr-data demote TABLE_
 schedule and withdraws the live pointer. Read the resulting table state, but do not infer a
 schedule, catch-up, or current bytes from the command name or from route acceptance.
 
+To retire several tables, do it in two commands rather than a loop: `mr-data demote TABLE_ID
+TABLE_ID ...` withdraws them, then `mr-data table archive TABLE_ID TABLE_ID ... --confirm DELETE`
+retires them. `DELETE` is the literal word and nothing else is accepted; it confirms the
+identifiers you typed, and each table is then retired under the name Studio is holding for it, so
+you do not have to look any name up. Neither command stops at the first refusal: both attempt every
+table, print one outcome line for each, and exit non-zero if any did not move. Read the per-table
+outcomes — `--json` carries them as an array with counts beside it — and report what happened to
+each table rather than what the exit code said about the set. A table that is live is refused by
+`archive` until it is withdrawn, and a table a run is still writing to is refused by both until the
+run has finished; neither refusal deletes anything, and neither ends the command.
+
 ## Autonomous delivery
 
 Own the run until the requested outcome is delivered: a run that succeeded, its declared checks

{mostlyright_data-0.14.1 → mostlyright_data-0.14.2}/src/mostlyright/data_harness/stream_subscription_sealer.py

@@ -27,6 +27,7 @@ from mostlyright.data_harness.canonical import (
     parse_json,
     sha256_bytes,
 )
+from mostlyright.data_harness.hosted_stream_recorder_job import _sort_series_documents
 from mostlyright.data_harness.ingestion.gcs_store import (
     GCSObjectTransport,
     GCSPreconditionFailed,
@@ -40,6 +41,7 @@ from mostlyright.data_harness.sources.stream_registry import (
     load_stream_connector_registry,
 )
 from mostlyright.data_harness.sources.stream_segment_recorder import StreamSegmentRecorder
+from mostlyright.data_harness.sources.stream_series import SERIES_DIRECTORY_NAME
 from mostlyright.data_harness.stream_subscription_worker import (
     MAX_DISCOVERY_EVIDENCE_BYTES,
     CheckpointReservation,
@@ -435,6 +437,18 @@ def _materialize_registry(
         registry_digest=_required_claim_value(claim.connector_registry_digest, "registry digest"),
         root=registry_root,
     )
+    # THE REGISTRY A SERIES SUBSCRIPTION PINS HOLDS TWO GRAMMARS. A published registry is one
+    # flat name-to-digest table, and a subscription that follows a series pins a registry that
+    # carries the series document beside the connector it rotates. The connector loader reads
+    # every document directly beneath the root and refuses one written in the series grammar,
+    # so the series documents are filed under the series directory first -- exactly as the
+    # claim path (`hosted_stream_subscription_worker._materialized_claim_connector`) and the
+    # bounded recorder job already do. Without this, sealing died on the first checkpoint of
+    # every series-following subscription with STREAM_CONNECTOR_DOCUMENT, the lease was lost
+    # before any segment landed, and the subscription terminalized after five lost leases.
+    series_root = root / SERIES_DIRECTORY_NAME
+    series_root.mkdir(mode=0o700, exist_ok=True)
+    _sort_series_documents(root, series_root)
     return load_stream_connector_registry(root)
 
 

{mostlyright_data-0.14.1 → mostlyright_data-0.14.2}/src/mostlyright/data_harness/thin/router.py

@@ -135,10 +135,10 @@ HOSTED_SUMMARY = dict(
             "ask Studio to publish one table and report only returned continuation evidence",
         ),
         ("reschedule", "change how often one table refreshes, without starting a run"),
-        ("table", "report what one table is serving, rename it, or retire it"),
+        ("table", "report what one table is serving, rename it, or retire one or many"),
         ("pin", "ask Studio to pin the live pointer and report the returned state"),
         ("unpin", "ask Studio to remove a pin and report the returned pointer state"),
-        ("demote", "ask Studio to withdraw the live pointer and report schedule state"),
+        ("demote", "ask Studio to withdraw the live pointer from one table or many"),
         ("watch", "stream one run's live progress, resuming across stream cuts"),
         ("download", "bring one run's artifacts back here, each one's digest checked"),
         ("receipt", "print the record one run sealed about how it was built"),
@@ -439,15 +439,22 @@ def _exit_codes() -> dict[str, Callable[[dict[str, Any]], int]]:
     ``ux.commands.CommandSpec`` gives: an exit code that can disagree with the printed answer is
     an exit code somebody will trust over the answer.
 
-    Six entries, and all six are answers a script acts on rather than reports it reads: a run held
-    at the spend gate has not started, a run that failed is not a build whichever surface it was
-    learned from, a table whose declared checks did not all pass is not one to go on with, a
+    Eight entries, and all eight are answers a script acts on rather than reports it reads: a run
+    held at the spend gate has not started, a run that failed is not a build whichever surface it
+    was learned from, a table whose declared checks did not all pass is not one to go on with, a
     question this command stopped waiting on has not been answered, and a probe that settled
     without an answer is not a yes. Everything else in the lane reports.
+
+    ⚠ THE LAST TWO ARE MOUNTED FOR THE NAME AND NOT FOR THE ACT, which is why one function serves
+    both. ``mr-data table archive`` and ``mr-data demote`` each take a LIST and never stop at the
+    first refusal, so "did it work" is a question about the whole list and only the counts can
+    answer it. ``mr-data table TABLE`` and ``mr-data table rename`` reach the same entry, carry no
+    counts, and exit ``0``: a report is not a gate, and the derivation says so rather than the
+    router keeping a second table of which halves of a name are which.
     """
 
     from mostlyright.data_harness.thin import probe as probe_module
-    from mostlyright.data_harness.thin import v4_artifacts, v4_query, v4_runs, v4_stream
+    from mostlyright.data_harness.thin import v4_artifacts, v4_query, v4_runs, v4_stream, v4_tables
 
     return {
         "run": v4_runs.run_exit_code,
@@ -456,6 +463,8 @@ def _exit_codes() -> dict[str, Callable[[dict[str, Any]], int]]:
         "checks": v4_artifacts.checks_exit_code,
         "query": v4_query.query_exit_code,
         "probe": probe_module.probe_exit_code,
+        "table": v4_tables.lifecycle_exit_code,
+        "demote": v4_tables.lifecycle_exit_code,
     }