mirror of
https://github.com/the-draupnir-project/Draupnir.git
synced 2026-10-23 01:21:16 +00:00
Tests / Build & Lint (push) Canceled after 0s
Tests / Unit tests (push) Canceled after 0s
Tests / Integration tests (push) Canceled after 0s
Tests / Application Service Integration tests (push) Canceled after 0s
Ci in a Box / Build & Lint / Node 24 / alpine / amd64 (push) Canceled after 0s
Ci in a Box / Build & Lint / Node 24 / slim / amd64 (push) Canceled after 0s
Ci in a Box / Build & Lint / Node 26 / alpine / amd64 (push) Canceled after 0s
Ci in a Box / Build & Lint / Node 24 / alpine / arm64 (push) Canceled after 0s
Ci in a Box / Build & Lint / Node 24 / slim / arm64 (push) Canceled after 0s
Ci in a Box / Unit tests / Node 24 / alpine / amd64 (push) Canceled after 0s
Ci in a Box / Unit tests / Node 24 / slim / amd64 (push) Canceled after 0s
Ci in a Box / Unit tests / Node 26 / alpine / amd64 (push) Canceled after 0s
Ci in a Box / Unit tests / Node 24 / alpine / arm64 (push) Canceled after 0s
Ci in a Box / Unit tests / Node 24 / slim / arm64 (push) Canceled after 0s
Ci in a Box / Integration tests / Node 24 / alpine / amd64 (push) Canceled after 0s
Ci in a Box / Integration tests / Node 24 / slim / amd64 (push) Canceled after 0s
Ci in a Box / Integration tests / Node 26 / alpine / amd64 (push) Canceled after 0s
Ci in a Box / Integration tests / Node 24 / alpine / arm64 (push) Canceled after 0s
Ci in a Box / Integration tests / Node 24 / slim / arm64 (push) Canceled after 0s
Ci in a Box / Application Service Integration tests / Node 24 / alpine / amd64 (push) Canceled after 0s
Ci in a Box / Application Service Integration tests / Node 24 / slim / amd64 (push) Canceled after 0s
Ci in a Box / Application Service Integration tests / Node 26 / alpine / amd64 (push) Canceled after 0s
Ci in a Box / Application Service Integration tests / Node 24 / alpine / arm64 (push) Canceled after 0s
Ci in a Box / Application Service Integration tests / Node 24 / slim / arm64 (push) Canceled after 0s
Validate Docker Build / validate-docker-build (push) Canceled after 0s
Docker Hub - Develop / docker-latest (push) Canceled after 0s
GHCR - Development Branches / ghcr-publish (push) Canceled after 0s
* Split the Projection interface into distinct reader / writer sides. https://github.com/the-draupnir-project/planning/issues/150 * Add ProjectionDescription and make it hold the shape. https://github.com/the-draupnir-project/planning/issues/152 * Expand ignore pattern for unused vars Type paraemters weren't included mew * Add a builder for protection descriptions. https://github.com/the-draupnir-project/planning/issues/152 * WIP: begin using projection locator * Rename ProjectionLocator to ProjectionAllocator and wire in. The reason why we can't have an orchestrator own the projects yet is simply because currently the projections are created from _protected rooms set_ specific revision issuers that are disposed alongside it. And of course if we were naive and implemented the global orchestrator, we'd be tied to a stale protected rooms set if a Draupnir was restarted via safe mode or whatever. * Remove the projection allocator. The problem with it is that we would be tunneling through the dataflow from source to sink, not from sink to source. But the allocator is designed for sink to source. Which is an issue because the ownership semantics from source to sink are the desired ones (the orchestrator owns the projections and is a global thing that caches them). But from sink to source, ownership is adhoc and they can't be cached at all because context is needed from the non-ported parts of the upstream data pipeline. Which tbh are effectively non deterministic sources as far as the orchestrator engine is concerned. Additionally, using the projections or projection nodes from code outside of the reducer pipeline will always require allocation of a live handle. This is because of a few reaons: 1. GCing old projection nodes that are lazy loaded requires there are no live handles. 2. Managing cache of projection nodes (including via a Projection) on workers requires knowing if they are being accessed. I don't think there are other reasons. So this really is the API to get right. And i don't think it's easy while projections are muddled with context.