DEV Community: Ivan Rossouw

A Page Is Not Shipped Until People Can Find It

Ivan Rossouw — Fri, 25 Sep 2026 06:06:10 +0000

A routed page can compile, pass its authorization checks, have documentation, and still be functionally absent. If the people entitled to use it cannot discover a normal way in, the product behaves as though the capability was never built.

That is easy to miss in a modular Blazor application. One team adds pages in one project, another module owns a second page tree, and a central hub or navigation catalogue tries to present the whole product coherently. Each local change can look correct while the experience between modules quietly breaks.

The remedy is not another release checklist. It is an executable discoverability contract.

Define the invariant at the page boundary

A useful rule is simple:

Every static operational page must have one intentional entry point whose visibility matches the page's access rule.

“Static” matters. A detail page with an identifier in its route is normally reached from a list, search result, or parent screen. It does not need a global menu item. A screen that answers on two route aliases is still one page; adding two cards would create duplication rather than discoverability.

The rule should cover pages, not merely strings that resemble URLs. That keeps the test aligned with the product concept people actually use.

It should also say “intentional entry point,” not “mentioned somewhere.” A link buried inside another page may technically make a route reachable, but it does not necessarily make the capability findable. Likewise, a help article that names a screen is documentation, not navigation. Requiring a deliberate card or menu entry forces the information architecture to be explicit.

Scan every module, not only the original tree

Architecture tests often begin with a useful local assumption: all administrative pages live under one directory, namespace, or assembly. The test passes for years. Then a new module introduces another tree and the guard continues to report green because it never sees the new pages.

This is a particularly awkward failure because both the feature and the guard are “working as designed.” The design boundary is simply stale.

The test therefore needs a completeness check as well as a matching check. Enumerate every known page tree. Parse the routed components. Exclude only clearly contextual routes. Then compare the resulting pages with the navigation catalogue.

Add a sanity assertion too. If a mature tree suddenly produces zero—or far fewer—pages, the parser or directory assumption probably broke. Without that guard, a failed scan can look like perfect compliance.

When a new module owns pages, extending the scan is part of integrating that module. This turns architectural coverage into an explicit responsibility rather than inherited folklore.

Keep navigation and authorization separate

The navigation entry should use the same access decision as the destination page. If the card is broader, people see an invitation that ends in refusal. If it is narrower, people who are entitled to use the page cannot find it.

It is tempting to reuse a nearby permission because it is convenient. That can be wrong in both directions. When no existing decision expresses the page's real audience, adding a focused visibility flag is usually clearer than bending an unrelated one.

But matching visibility does not turn navigation into security. A hidden card only changes what the interface presents. A direct request, a bookmarked address, or another client can still reach the endpoint. The page or server operation must continue to enforce authorization independently.

This separation produces a healthy pair of invariants:

navigation makes entitled capabilities discoverable;
authorization rejects requests that are not entitled.

Testing both is stronger than asking either mechanism to do two jobs.

Prefer a precise contract over “linked somewhere”

A broad reachability scan can be a good first diagnostic. Search the codebase for links to each route and identify pages that have no inbound reference. That quickly reveals obvious orphans.

As a permanent contract, however, “linked somewhere” is weak. A tab rail is visible only after someone has already reached a page in that tab set. A contextual link may depend on data or state. A help page may mention the route without providing product navigation. Source text can prove that a string exists; it cannot prove that the intended audience has a clear entry point.

Tightening the rule to require the chosen navigation catalogue makes the standard less ambiguous. It also creates useful pressure: when a page fits nowhere, the team must decide whether the navigation model is incomplete, the page is contextual, or the feature should not be exposed yet.

Accept the maintenance cost deliberately

The stricter contract adds work. New pages need catalogue entries, accurate visibility mapping, and suitable grouping. Route conventions must be understood well enough for the test to distinguish static pages, detail pages, and aliases. Large navigation surfaces may expose sections that no longer fit their historical categories.

Those are not test problems to hide with a long exemption list. They are product and architecture decisions the test has made visible.

Keep exemptions small, named, and justified by a navigation model rather than by inconvenience. Fail when an exemption becomes stale. If a page genuinely belongs behind a list or workflow, encode that reason. If it is an operational destination, give it an intentional entry point.

The payoff is modest but durable: completed capabilities do not disappear between modules, permission drift becomes easier to see, and a new page cannot quietly land outside the product's navigation contract.

A page is not shipped merely because its route exists. It is shipped when the right person can find it—and the wrong person still cannot execute it.

Remove a Workspace Member Safely from Blazor

Ivan Rossouw — Fri, 25 Sep 2026 05:13:29 +0000

Remove a Workspace Member Safely from Blazor

A destructive UI should protect the operator's intent without pretending that browser state is authoritative. This slice adds a Blazor workspace-member page on top of an existing owner-authorized ASP.NET Core removal command.

Treat the roster as a snapshot

The page loads an allow-listed member projection containing a user identifier, email, numeric role, concurrency version, and current-user marker. The client defines its own transport record and rejects unknown roles, blank fields, duplicate identifiers, non-positive versions, null content, and unmapped members. Both the browser request and server response use no-store semantics so an explicit recovery refresh reaches the current server state.

Only another ordinary member exposes a remove action. Selecting it captures the identifier, email, and displayed version together. Confirmation names the member and sends no request until the owner accepts. Starting any refresh clears that snapshot first, preventing an old confirmation from surviving beside a newer roster.

Keep the HTTP result finite

The POST route contains the encoded target identifier, while the body contains only expectedVersion. The adapter maps No Content, Unauthorized, Forbidden, Not Found, invalid-version, stale-version, and transfer-required outcomes into explicit result types. Malformed bodies, unknown codes, unexpected statuses, and transport failures become one safe Failure result.

Timeout-style operation cancellation becomes Failure so the page enters stale lock. Cancellation explicitly requested through the caller token still propagates, which avoids showing a false network warning during navigation or disposal.

Refresh after the server decides

The page never removes a row optimistically. After success it reloads the server roster and announces the result. If that reload fails, it says the command completed but the visible roster could not be refreshed. A stale conflict also reloads, but it never retries the destructive command automatically. The owner must inspect the new row and choose again.

Any unclassified failure retains the last good roster for context, shows the exact stale warning, disables every remove action, and leaves Refresh available. Only a successful validated load clears that lock.

Focus after rendering

Conditional confirmation and result elements do not exist until Blazor renders them. The component queues a semantic focus target, then uses OnAfterRenderAsync and ElementReference.FocusAsync. Programmatic headings and messages use tabindex minus one. Cancel returns to the initiating row action when it still exists; otherwise focus falls back to the roster heading.

Prove both sides of the boundary

Typed-adapter tests pin the wire contract, cache mode, status mapping, cancellation behavior, and strict validation. bUnit tests drive confirmation, cancellation, refresh invalidation, success reload, stale locking, access failure, and the ambiguous case where removal succeeds but refresh fails. Existing integration tests continue to prove workspace scoping, owner authorization, optimistic concurrency, SignalR eviction, and old-token denial.

The result is a small vertical slice with a useful rule: the UI protects intent, the version identifies the reviewed snapshot, and the server decides whether the command is still valid.

A Retry Is Not Safe Until the Side Effect Is Safe

Ivan Rossouw — Thu, 24 Sep 2026 05:56:03 +0000

A retry can duplicate a side effect even when the original command completed successfully.

This is easy to miss in a method that does two ordinary things: save a record and send a message. Each operation is understandable on its own. The difficult part is the uncertainty between them.

Suppose an endpoint creates an invitation, persists it, asks an email provider to deliver a link, and returns a response. The database commit succeeds. The provider may accept the message. Then the network drops the response. The client cannot tell whether anything happened, so it retries.

If the server repeats the whole method, it can create another record, another secret, or another email. The code has turned a lost response into duplicated authority-bearing side effects.

The lesson is broader than invitations: design the durable commit point, provider boundary, and retry contract as one workflow.

Commit the fact before announcing it

Sending before saving creates the most confusing failure mode. A recipient receives a plausible link, but the backing operation never committed. To them, the system appears to reject a valid action for no visible reason.

A safer ordering is:

Validate the command.
Create the durable operation.
Store an idempotency receipt that points to that operation.
Commit both together.
Only then ask the external provider to send.

The durable record becomes the source of truth. The message announces a fact that already exists rather than promising that a later write will probably succeed.

This does not make the database and email provider atomic. It gives the gap between them explicit semantics.

Make replay return, not repeat

An idempotency key is useful only when it protects the irreversible side effect too.

The receipt should bind a caller-generated command key to a stable fingerprint of the request. If the same key returns with the same request, the service reads and returns the original result. It does not send again. If the key returns with different input, the service rejects the conflict rather than guessing which request the caller intended.

The database should also enforce uniqueness. Two identical requests can arrive concurrently before either sees the other's receipt. Let one commit win; have the loser load and return the winning result. Otherwise a perfectly designed application check can still race.

The important invariant is not merely “one row.” It is “one durable result and one automatic send for one command.” Tests should assert both.

Unknown is not the same as failed

Provider calls rarely produce only success or failure. They produce at least three useful outcomes:

Accepted: the provider acknowledged the message.
Definitely rejected: the provider did not accept it.
Unknown: the caller lost certainty, often through a timeout or interrupted response.

Unknown is the dangerous one. The message may already be queued. Reporting a definite failure can encourage an immediate retry and a second message.

This is a small state-model decision with a large operational effect. Do not collapse “I do not know” into “it did not happen.” Preserve uncertainty so the recovery path can respond deliberately.

Keep a recovery handle

If delivery is definitely rejected after the database commit, deleting or closing the record may feel tidy. It also removes the user's only handle on the problem.

Keeping the durable operation pending can be more honest. The UI can show that it exists, report that delivery failed, and offer an explicit resend. That resend is a new action, not a transparent replay of the original command.

For a message carrying a secret, explicit resend should rotate the secret, invalidate the old link, persist the new state, and then send. Leaving both links active multiplies hidden authority. Reusing a raw secret is often impossible or unsafe if only its hash was stored.

This recovery model needs expiry, status visibility, observability, and clear language. “Pending” must not imply “delivered.” The system should say what it knows and avoid claiming what it cannot know.

Test the gaps, not only the happy path

The valuable tests live at the boundaries:

Repeating the same command returns the same result, leaves one durable record, and sends once.
Concurrent duplicates converge on one receipt and one result.
A definite pre-provider rejection is reported while the recovery record remains available.
An unknown outcome is not presented as definite non-delivery.
Explicit resend invalidates the earlier secret before attempting delivery again.
The provider is never called before the database commit succeeds.

These tests express the reliability contract better than a broad “request succeeds” test. They also make later refactoring safer because the order and meaning of side effects are visible.

The trade-off is honest complexity

This design is not free. It introduces command receipts, request fingerprints, provider outcome types, pending states, expiry, and explicit recovery. Operators need enough telemetry to distinguish rejected sends from unknown outcomes. Product language must explain uncertainty without alarming users.

The alternative is simpler code with less truthful behaviour: phantom links, duplicate messages, or retries that silently create extra authority.

My practical review question is: for every workflow that combines a database write with an external side effect, can we point to the commit point, replay rule, uncertainty model, and recovery action?

If those four answers are explicit, retries become a designed part of the workflow rather than a hopeful repetition of it.

Transfer Workspace Ownership Atomically

Ivan Rossouw — Wed, 23 Sep 2026 21:49:54 +0000

Ownership is not two unrelated role edits. It is one invariant over two active membership rows: the supported transfer command replaces the current owner with exactly one member.

Trust the server boundary

The browser proposes a target user and the two versions shown in its roster. The server derives the acting user and workspace from authenticated state, then rechecks the live owner membership and security stamp inside the transaction. A foreign or inactive target is never allowed to choose its way into the workspace.

Combine isolation and optimistic versions

A serializable transaction makes the decision and write one unit. Both membership Version properties are EF Core concurrency tokens, so the displayed owner and target versions must still match. Isolation orders concurrent work; optimistic versions explain that the operator's roster is stale.

On SQL Server, the candidate query uses UPDLOCK and HOLDLOCK in a stable order. This avoids the shared-lock upgrade deadlock that can occur when two serializable readers both intend to write the owner row. Other providers retain their normal tracked query inside the serializable transaction.

Change both roles and save once

The domain ChangeRole method accepts only active memberships, advances Version, and assigns the new role. The store demotes the old owner, promotes the target member, calls SaveChanges once, and commits once. EF checks both original versions. A conflict rolls back the pair and maps to a finite stale-version result.

Advancing both versions also invalidates old tenant-local authority. The existing policies compare the principal's membership version with the live selected membership. The former owner cannot retain owner access, and the promoted member must refresh before receiving new owner authority. Unrelated workspace memberships are untouched.

Prove the concurrency boundary

A provider-backed test starts two transfers through separate DbContext instances against SQL Server. Exactly one command succeeds. The other loses current authority or sees stale state. The final query finds exactly one Owner row, with both changed memberships advanced to version two.

The claim is intentionally scoped to supported application commands. Arbitrary out-of-band database edits can bypass application invariants and need separate operational controls.

Recommendations Are Not Decisions: Designing an Auditable Human Boundary

Ivan Rossouw — Wed, 23 Sep 2026 14:52:42 +0000

Software is very good at making a calculation look authoritative. Give a rule engine enough inputs and it can return a crisp result in milliseconds. In a consequential workflow, that neatness is dangerous: a computed recommendation can quietly become a decision without anyone deliberately granting it that authority.

A better design treats computation and authority as different responsibilities. The software may evaluate evidence, explain what it found, and suggest an outcome. A person still records the actual decision. The data model preserves both.

That separation is more than a user-interface disclaimer. It has to reach the evaluator, persistence model, activation workflow, and tests.

Keep the evaluator pure

Start with an evaluator that has no write path. It accepts a versioned rule and a set of observations, then returns an explanation:

which inputs contributed;
which requirements passed or failed;
what evidence was missing;
which rule version was used; and
what outcome, if any, is suggested.

The return value should say “suggested,” not “decided.” Naming is not sufficient, but it makes accidental authority harder to hide.

Purity matters here. A preview operation should be safe to run repeatedly without creating decisions, sending notifications, or mutating state. That keeps calculation testable and prevents a read-like action from acquiring an unexpected side effect.

When essential evidence is missing, the evaluator should return an advisory state with no suggestion. A nullable recommendation can be a feature: it says the software cannot justify a conclusion. Returning the most likely answer would make uncertainty easy to rubber-stamp.

Make rules prove their intended behaviour

Syntactically valid configuration is not the same as reviewed policy. A collection of thresholds can pass field validation and still express something the author did not mean.

Before a configurable rule becomes active, require named worked examples. Each example contains representative inputs and the outcome the author expects. Activation replays every example through the same evaluator used by real records. If one disagrees, activation stops.

Using the same evaluator is important. A second “fixture evaluator” would only prove that two implementations can disagree in production.

Malformed examples should fail before replay. If a parser silently misreads an input and the example happens to reach the expected result, the gate gives false confidence. An explicit failure is safer than a coincidental pass.

These examples act as executable policy conversations. They let reviewers ask, “What should happen in this borderline case?” before the rule affects a real decision.

Persist recommendation and decision separately

The final record should not overwrite the computed recommendation. Store both:

the recommendation available at decision time;
the outcome the person recorded;
the exact rule version that informed it;
the actor and timestamp; and
a reason when the decision departs from the recommendation.

This turns disagreement into useful data instead of treating it as an error to conceal. A departure may reveal legitimate context that the model deliberately does not represent. It may also reveal a weak rule. Either way, preserving both facts makes later review possible.

The same principle applies to overrides. Do not edit the old outcome in place. Append a new version, mark it as current, retain the previous value, and require a reason. Historical records should describe what was known and decided then—not what today’s configuration would calculate now.

Pinning the rule version is crucial. If a rule changes next month, an old decision must still point to the version that produced its original recommendation. Otherwise, history becomes a moving target.

Test the boundary, not only the formula

Formula tests are necessary, but the more revealing tests are often about authority and time.

Useful cases include:

previewing produces an explanation and writes nothing;
missing essential evidence produces no recommendation;
a rule without worked examples cannot be activated;
an example that disagrees with the rule blocks activation;
departing from a recommendation without a reason is refused;
an override appends a version instead of editing history; and
changing a rule later does not alter an already recorded decision.

These tests express the operating model. They protect not only mathematical correctness, but also who is allowed to decide and whether past context remains trustworthy.

Accept the deliberate friction

This approach costs more than returning an enum and saving it. It introduces draft and active rule states, advisory outcomes, versioned decisions, reasons, worked examples, and review steps. Operators need to understand the distinction. Developers have more invariants to maintain.

That friction should be proportional to consequence. A low-stakes recommendation may not need an append-only ledger. A decision affecting access, eligibility, money, safety, or a person’s future probably deserves more than an opaque calculation.

Worked examples also have limits. They prove that the authored rule behaves as expected on selected cases. They do not prove that the policy is fair, lawful, complete, or statistically sound. Human approval can still be mistaken. Permissions, peer review, monitoring, and periodic policy review remain necessary.

A practical design question

When reviewing a rule-driven workflow, ask one question first: is this output evidence for a decision, or is the system silently making the decision itself?

If the answer matters, create a visible boundary. Keep evaluation pure. Refuse to guess when evidence is insufficient. Gate activation with executable examples. Record human choices separately. Preserve departures and history.

The goal is not to weaken automation. It is to make its authority honest.

When a Green Test Protects the Wrong Authorization Rule

Ivan Rossouw — Tue, 22 Sep 2026 07:07:37 +0000

An automated test is useful only when its assertion represents the rule we intend to preserve. That sounds obvious until a test passes for the exact condition that should make a reviewer uneasy.

A recent Blazor change offered a concrete reminder. Two routed administrative pages required a signed-in user but did not assert a permission policy at the page. The links that led to them were filtered by permission. That made the interface look appropriately restricted, while a signed-in person could still enter the URL directly. Two existing tests expected the permissive page attributes, so the green suite helped the gap survive.

The engineering lesson is broader than those pages: when a test blesses an authorization omission, fix the assertion and add an invariant that catches the next omission. Keep the invariant honest about what it can and cannot prove.

Navigation visibility is a different boundary

Consider an administrative interface with a configuration card. The card appears only when the current viewer has a configuration permission. The destination page, however, asks only whether the viewer is signed in. Hiding the card changes what the viewer sees; it does not change what the route accepts.

The direct URL is the simplest counterexample. If the user knows or guesses it, the navigation filter is bypassed. A page-level policy is needed to decide whether that route may render for the viewer. The underlying API or command must make its own authorization decision as well. These checks serve different entry points, so one cannot stand in for the other.

In the inspected change, the page policies were added. One data endpoint already had a stricter authorization rule and kept it. The lesson is to review each boundary on its own terms: visible link, routed page, and operation.

Read assertions as product decisions

The surprising part was not that a page attribute was too broad. It was that tests explicitly expected that breadth. One assertion accepted the absence of a policy; another looked for a bare sign-in attribute. Those statements had made an implementation detail into a contract.

When correcting a test like this, start by naming the intended behaviour in plain language. For example: “This routed configuration page requires the configuration policy.” Then inspect the compiled authorization attribute and assert that policy. This makes the test follow the behaviour the framework will see, rather than a particular text fragment in a Razor file.

That specific test matters even if a broader scan exists. A scan can report that a policy is present, but a policy for an unrelated administrative task could still pass it. The page-specific assertion checks the narrower decision about which permission belongs there.

Turn the omission into an invariant

The change also added a structural test over routed administrative pages in two application areas. It checks whether each page asserts a permission policy. The test has a nonempty coverage guard, because a scan that accidentally finds zero pages is worse than a failing scan: it can look reassuring while doing nothing.

This is a useful pattern for requirements that should apply across a family of files. A single page test protects a known case. A route scan makes it harder for a new page to repeat the same omission. Neither test needs to simulate every user and role to answer the structural question, “Did this route declare a permission policy?”

The boundary of that answer is important. The scan does not prove that every declared policy is correct. It does not prove that an API rejects unauthorized calls. It does not prove that authorization is complete across the product. Those claims require different tests and review.

Make exceptions accountable

Some landing pages can legitimately be available to any signed-in viewer because their contents filter themselves by the viewer's permissions. A blanket rule that rejects every such page would create noise and encourage people to weaken the test. The committed scan therefore allows explicit exemptions with reasons.

An exemption is still a maintenance obligation. If a page is deleted, renamed, or later gains a policy, its old exemption should disappear. A second test checks for those stale entries. It keeps the exception list from becoming a historical catalogue that a future developer might mistake for permission to add more exceptions.

The two corrected pages are pinned separately. That matters because someone could otherwise make the broad scan green by putting a vulnerable page on the exemption list. The pinned tests say those particular pages must keep their policies and cannot be exempted.

The same change initially documented a separate unresolved permission decision as a known gap. A follow-up commit assigned that page a policy after an owner made the decision. Recording the gap first kept the review honest while the right policy was decided rather than guessed from a neighbouring page.

The practical review sequence

When a green test has protected the wrong rule, I use this sequence:

Reproduce the bypass at the relevant entry point in a controlled test or review, such as direct route access rather than clicking the navigation card.
State the intended permission and correct the local assertion so it checks the framework-visible attribute.
Add a structural invariant if the same omission can recur across many pages.
Give every real exception a reason, and make stale exceptions fail.
Keep page and operation authorization under separate review; presence of a page policy is only one piece of evidence.

This approach costs some test and exception-list maintenance. The benefit is a much earlier signal when another route omits a policy, while the specific assertions preserve the decisions that matter most. A green suite should mean that our intended boundary is holding, not merely that yesterday's implementation has stayed the same.

Revoke an Established SignalR Connection Safely

Ivan Rossouw — Mon, 21 Sep 2026 22:38:37 +0000

A successful membership removal stops new requests, but an existing SignalR connection may still carry an earlier principal and tenant group membership. Those are separate surfaces.

Track the minimum live state

Keep an in-process registry from tenant and connection ID to user ID. Avoid tokens, email addresses, and message bodies. A per-tenant gate coordinates admission, revocation, and outgoing broadcasts.

Validate both directions

On connection, check the exact tenant, membership version, and security stamp against the live row before joining the group. A hub filter repeats that check before each client-invoked method. A method check does not stop group delivery, so after a successful membership commit, remove the user's matching connection IDs from that tenant group.

State the ordering guarantee

A chat broadcast takes the same tenant gate and rechecks its sender before saving or sending. Once the removal response returns, a later broadcast cannot select the removed connection. A frame already dispatched before removal cannot be recalled.

Test an established connection

Hold real SignalR clients open during owner removal. The remaining member receives a subsequent message. The removed member receives none, its next send fails, and no rejected text appears in persistence. New-negotiation and tenant-isolation tests still run.

This registry is single-node. A multi-node deployment needs shared revocation coordination or a managed SignalR service. The next episode transfers ownership atomically.

Watch the 6-minute lesson: https://youtu.be/RFI5AaHbzMU

Offline Readiness Is a State-Machine Contract

Ivan Rossouw — Mon, 21 Sep 2026 06:07:16 +0000

“Make it work offline” often turns into a storage task: serialize the last successful response, read it when the network fails, and move on.

That is necessary, but it is not the hard part.

The hard part is deciding what the stored response means across launch, failure, reconnect, configuration change, and session recovery. Once a mobile application depends on runtime configuration, offline readiness becomes a state-machine contract. A cache is only one implementation detail inside that contract.

Find the contradictory assumptions first

Consider a .NET MAUI wrapper hosting a Blazor UI. A lower startup layer may correctly treat a reachability probe as diagnostic: the network can be absent, so failure should not prevent launch. But a higher layer may immediately call a runtime-configuration endpoint and require a successful answer before activating the application scope.

Each layer looks reasonable in isolation. Together they disagree.

The lower layer says, “reachability is not a launch gate.” The higher layer says, “no live response, no ready state.” A short outage is then presented as invalid configuration even though nothing has been invalidated.

This is why I like to draw the complete launch state machine before changing storage. List the states—uninitialised, resolving, ready from live data, ready from fallback data, unavailable—and name the events that move between them. Contradictions become much easier to see when they are transitions rather than scattered if statements.

Classify failure before consulting the cache

Not every failed request grants permission to use stale data.

A timeout, lost connection, or temporary server error says, “the current answer is unavailable.” A recent cached configuration may be the best safe answer.

An authoritative not-found or gone response says something different: “this configuration no longer exists here.” Serving the cache would override current server knowledge with old local knowledge. That is not resilience; it is refusal to accept invalidation.

So the order matters:

Attempt the live load.
Classify the failure.
Consider fallback only for the transient class.
Clear the fallback when an authoritative response makes it wrong.

This distinction is reusable well beyond configuration. Offline permissions, feature manifests, routing metadata, and other control-plane data all need an explicit invalidation rule.

Make “recent enough” a real policy

Even a transient failure does not make every cached value safe.

A useful policy checks at least four things. The entry must belong to the same logical scope. It must come from the same configured source. Its age must be within a deliberate bound. Its timestamp must not be implausibly far in the future.

Source binding is easy to miss. Runtime configuration often contains addresses and capability switches. If an application is repointed but continues serving a cache captured from the old source, it may look healthy while sending work to the wrong place. Treating a source change as a cache miss is safer and easier to reason about.

The age bound is a product and operational decision, not a magic constant. It should cover the outages the application is expected to tolerate while still placing a limit on how long retired configuration can survive. Document the reasoning so the next engineer knows whether changing it is a reliability decision or a cosmetic edit.

Clock skew deserves a rule too. A future-dated entry can otherwise remain “fresh” for far longer than intended.

Preserve continuity when connectivity returns

An application that opens from fallback data is usable, but not settled. It should carry an explicit “needs refresh” hint.

When connectivity returns, the tempting implementation is to rerun the entire startup pipeline. That can be surprisingly destructive. Full reinitialisation may advance a session epoch, cancel in-flight requests, clear actor state, restart background rails, and remount the renderer. On a flapping connection, users can pay that cost repeatedly.

Prefer an in-place refresh while the current scope remains valid. Update the runtime configuration, clear the refresh hint, and let the active session continue. Escalate to full resolution only if the refresh proves that the scope disappeared or changed in a way that makes continuity unsafe.

This gives reconnect two distinct transitions:

unavailable to online: resolve fully because there is no active scope to preserve;
ready-from-fallback to online: refresh in place because there is useful state to protect.

Those transitions may share a network event, but they should not share an indiscriminate reset.

Let storage fail softly—and test the wiring

Device storage is another dependency, not a certainty. Reads can fail, writes can fail, and cleanup can fail. If a cache exists to make cold start more resilient, an escaping storage exception must not become a new cold-start crash.

Fail-soft behaviour should be intentional: a failed read behaves like a miss, a failed write loses future offline convenience, and a failed clear remains bounded by the expiry policy. Cancellation is different and should still propagate.

Test the serializer separately with round trips. A cache that writes successfully but cannot read its own format is indistinguishable from having no fallback at all.

Also test dependency-injection resolution through the real container. Optional constructor dependencies are convenient, but they can compile and quietly fall back to a null implementation when registration is missing. A focused integration test proves that the platform adapter actually reaches the service.

The trade-off is explicit complexity

This design is more complex than “try the network, then read a file.” It introduces failure classification, cache provenance, expiry, clock rules, lifecycle state, reconnect transitions, serialization, and a wider test matrix.

That complexity is buying something concrete: continuity without pretending stale configuration is always correct.

The practical review question is not, “Do we have a cache?” Ask instead:

Which state are we in, what evidence permits this fallback, and what is the least disruptive path back to live truth?

If the implementation can answer that clearly, offline readiness has become a deliberate contract rather than an accidental side effect.

Pagination Is a Consistency Contract

Ivan Rossouw — Sun, 20 Sep 2026 07:51:38 +0000

Page numbers feel harmless. They are familiar, easy to render, and easy to explain. But on a mutable work queue, they can lie.

Imagine a reviewer reading a newest-first queue. They load the first 25 items. Before they request the next page, a new item arrives at the top. An offset such as skip 25 now starts one row later than it would have a moment ago. The last row from page one may appear again, and the row displaced by the insert may never appear in that walk.

Nothing crashed. No error was logged. The interface simply presented an inconsistent view of the work.

The engineering lesson is that pagination over changing data is a consistency contract, not a decorative control beneath a table.

Begin with the mutation model

The right pagination strategy depends on how the collection changes.

For an append-mostly queue ordered newest first, new work normally arrives above the operator's current position. Other fields, such as workflow status, may change while the operator is reviewing an item. Those two facts suggest a useful boundary: continue from something fixed when the item entered the queue, not from a mutable field and not from the current numeric position.

A submission timestamp can provide that boundary if it is frozen when the item is created. Status usually cannot; ordering by status lets a decision move rows between pages while someone is walking the list.

The principle is broader than timestamps: choose an ordering key whose meaning remains stable for the duration of a walk.

Make the server own the continuation

A client should not reconstruct position from a page number, a visible row, or a guessed offset. The server should return an opaque continuation and accept it unchanged on the next request.

For a newest-first queue, a continuation can describe the last timestamp boundary and how many rows at that exact instant have already been emitted. The next query includes rows at or below the boundary, skips only the already-seen ties at that boundary, and takes one extra row to determine whether another page exists.

Why count ties instead of comparing an identifier? Identifier ordering is not always portable across database providers. Let the query provider apply its established ordering, and record only how far through the boundary group the walk has progressed.

Opaque does not mean unchecked. Reject blank, malformed, oversized, or unsupported continuations. A bad continuation should not silently restart at the top, because a restart looks like valid data with unexplained duplicates.

Bind position to query context

A continuation names a position in one specific ordered result set. Change the filter and that position may no longer mean anything.

Suppose page one was filtered to one workflow cycle, then the same continuation was replayed with the filter removed. Honouring it could skip rows that were never part of the original walk. The continuation should therefore carry enough context to prove it belongs to the active query. If the context differs, refuse the request and let the client restart explicitly.

The same discipline applies to page size. Put a small upper bound in the contract and reject values outside it. Quietly shrinking an oversized request hides caller mistakes; accepting it defeats the point of paging.

Bounding the first query is only half the work. If each row needs evidence, comments, or another related record, fetch those details only for identifiers on the current page. Otherwise an apparently paged endpoint can still perform an unbounded secondary read.

Preserve the operator's place

Continuation cursors naturally move forward. A usable review screen also needs Back and refresh.

The client can keep a short trail of the server-provided continuations used to open each visited page. Previous then replays the cursor that originally opened the prior page. The client is not interpreting the cursor; it is remembering the path.

After a reviewer changes an item, refresh the page they are currently viewing. Returning to page one after every decision is technically simple and operationally punishing. It also encourages people to work around the interface rather than trust it.

There is one awkward edge case: a later page may become empty before it is refreshed. Do not render a global empty-state message that implies the entire queue has vanished. Reset to the first page and show the current truth from a valid starting position.

Test the walk, not only the query

Happy-path tests that assert “25 rows returned” are not enough. The important properties live between requests.

Useful executable checks include:

a new item arriving above the boundary neither duplicates nor hides an existing row;
a workflow status change does not alter page membership;
several items sharing one timestamp are neither repeated nor lost;
a continuation cannot be replayed with a different filter;
malformed continuations and invalid page sizes are refused;
forward and backward navigation use the exact server continuations;
a write refreshes the active page; and
an empty later page recovers without claiming the whole queue is empty.

These tests describe the contract more clearly than the word “paged” ever could.

The trade-off is explicit complexity

Cursor paging asks more of both sides. The server must define and validate a stable continuation. The client must retain a small history. Ties and disappearing pages need deliberate behaviour. Troubleshooting is less intuitive than looking at page=3 in a URL.

In return, database work stays bounded and a reviewer can walk a changing queue without silent duplicates or gaps. That is a worthwhile trade whenever missing one item matters more than keeping the paging code superficially simple.

Before choosing offsets for a mutable list, simulate one insert and one update between consecutive requests. If the same walk no longer produces the same set of rows, the pager needs a stronger contract.

When EF Core Sees Only Part of Your Model

Ivan Rossouw — Sat, 19 Sep 2026 12:18:25 +0000

Framework warnings are valuable because they turn hidden risk into visible friction. But a warning is still an interpretation of the evidence available to the tool. In a modular application, the command-line process may not load the same assemblies as the running application. When that happens, the design-time model can be a projection rather than the whole truth.

That creates an uncomfortable situation: a migration warning may be both technically correct about the model it sees and dangerously wrong about the database operation it proposes.

The answer is not to ignore warnings casually. It is to identify the boundary, narrow the exception, and replace the lost signal with a stronger executable invariant.

The model can change with the process

Consider a lower-level persistence module that owns a database context. At runtime, higher-level modules can contribute entity configurations through a discovery mechanism. This preserves the dependency direction: the lower-level module does not need references back to every feature that extends it.

Now run command-line migration tooling from the lower-level project. The higher-level contributor may not be loaded, because adding that reference would create a project cycle. The tool builds a valid model, but it is only the portion visible from that process.

The migration snapshot, meanwhile, includes the contributed table. It was created from the full application model and must remain there for every host that uses the shared schema.

The differ compares those two views and concludes that the table exists in the snapshot but not in the current model. Its proposed fix is logical from that narrow perspective: drop the table.

From the system’s perspective, that operation is destructive.

Do not “fix” the snapshot to match a blind spot

Regenerating the snapshot until the warning disappears is tempting. It is also exactly the wrong response when the design-time model is incomplete by construction.

The first diagnostic question should be: what is the entire proposed difference? A probe migration can make the answer concrete. If the only change is removal of a table supplied by a module that the tooling process cannot load, the warning describes a visibility gap—not necessarily real drift.

This distinction matters. “The warning is a false positive” is too broad. A particular warning, for a particular context, under a documented loading boundary may be a false positive. Other differences could still be real.

The safe decision is therefore narrow: allow the legitimate database-update path to proceed despite that one known condition, while keeping a separate full-model comparison as the authoritative drift test.

Suppression spends a safety signal

Ignoring a warning removes friction. It does not remove the underlying ambiguity.

If a design-time factory suppresses a known pending-model warning, the team has spent a safety signal. That signal should be replaced with evidence closer to the failure mode.

In this case, the feared outcome is not an abstract “model mismatch.” It is a migration that drops, renames, or damages a table the design-time process cannot see. That can be tested directly.

An executable migration guard can inspect the operations produced by every committed migration and fail when it finds:

a drop of the protected table;
a rename that moves it out of the contract;
a column removal targeting that table; or
raw SQL containing the destructive operation.

This is more specific than the original warning, and that specificity is a strength. The test says exactly which invariant must survive.

Negative guards need positive controls

There is a subtle testing trap here. A test that scans migrations and finds no forbidden operation can pass because the migrations are safe—or because discovery found nothing.

That is a vacuous pass.

Add a positive control that proves the scan sees the migration that originally created the protected table. Now the pair of tests establishes both halves of the claim:

the evidence set is present; and
none of that evidence violates the destructive-operation invariant.

This pattern generalizes well. Whenever a test says “nothing bad exists,” pair it with proof that the search space is populated. It is useful for dependency scans, authorization maps, route inventories, migration checks, and reflection-based conventions.

Keep the full model as the authority

The migration guard protects one known destructive edge. It does not prove that every legitimate model change has a migration.

For that, retain a snapshot comparison that runs in a process where all runtime contributors are loaded. That test compares the snapshot with the full model rather than the design-time projection.

These checks have different jobs:

the full-model comparison detects real snapshot drift;
the migration guard blocks the known destructive artifact;
the positive control proves the guard actually inspected meaningful input; and
the narrowly scoped suppression keeps the operational update path usable.

Together, they are stronger than treating one framework warning as universally authoritative.

The trade-off is deliberate maintenance

This approach is not free. The guard knows about a specific architectural boundary. If extension mechanics change, the tests and documentation must change with them. Contributors need to understand why the suppression exists and why generated migration output still requires review.

The alternative is worse: either block legitimate operations forever, or normalize a habit of dismissing warnings and accepting generated drops.

The practical review rule is simple: when tooling sees only a projection, document the blind spot, scope the exception, and encode the real safety property as a failing test. Framework diagnostics are excellent inputs. Your architecture still owns the final claim.

A Successful Security Call May Prove Nothing

Ivan Rossouw — Thu, 17 Sep 2026 05:45:36 +0000

Security integrations often fail in a surprisingly polite way. The library loads. Initialization succeeds. The function returns. Nothing crashes. Yet the protection we expected may not have participated at all.

That distinction matters when an application accepts untrusted documents that another person may later open. The relevant question is not “did the scanning API answer?” It is “did a real security engine inspect this content and produce a trustworthy verdict?”

A recent engineering change reinforced a pattern worth carrying into other systems: prove the capability end to end, fail closed when the proof is missing, and preserve the difference between malicious content and content that has not been judged.

Integration health is not capability health

Suppose an operating-system security interface sits between your application and whichever antimalware product is installed. It is tempting to treat successful initialization as a health check. A clean transport result feels even stronger: the call returned normally and reported nothing detected.

But an integration layer and its downstream provider are separate things. The interface can be present while the engine behind it is stopped, unavailable, or incorrectly registered. In that condition, a nominal response may demonstrate only that the front door opened.

This is a general reliability problem, not an accusation against one API. Message brokers can accept a connection while a critical consumer is stalled. A secrets client can authenticate while the expected key is unavailable. A feature-flag SDK can initialize while serving stale defaults. Health must be defined by the capability the application depends on, not by the first component in the chain.

For a document scanner, “the library loaded” is weak evidence. “A known signal travelled through the production scanning path and produced the expected security verdict” is much stronger.

Test the behaviour you actually depend on

The design used a harmless standard test signal that security engines are expected to recognize. The literal signal does not belong in application content or public examples; what matters is its role.

At startup, the application sends that signal through the same in-memory scanning boundary used for uploaded bytes. The feature is registered only if the expected detection comes back. On unsupported hosts, or when no live engine answers, the risky upload capability remains unavailable.

That is a capability probe. It asks the downstream system to demonstrate the exact category of behaviour the application needs before the application trusts it.

The same proof is repeated when a scan begins. Startup checks become stale. A service can stop, a provider can be disabled, or policy can change while the host remains running. Rechecking at the point of use makes failure visible before untrusted content is accepted as safe.

This does add work. A liveness probe consumes a small amount of time, and the application may temporarily deny uploads during a dependency outage. That cost is deliberate. Availability is being traded for an honest security boundary rather than for a comforting but unsupported status flag.

“Malicious” and “not judged” are different states

Failing closed does not mean treating every failure as malware.

A positive engine verdict can justify refusing a document. An administrator policy may also explicitly block it. Those are security decisions based on evidence.

An exception is different. The bytes may be missing. The scanning interface may fail to initialize. The engine may disappear between startup and use. None of those facts proves that the document is malicious. They prove that the system does not have a verdict.

A useful state model keeps at least three outcomes separate:

Cleared: the control produced an acceptable verdict.
Refused: the control positively detected or blocked the content.
Pending: the system could not obtain a trustworthy verdict.

Collapsing the third state into “cleared” silently weakens security. Collapsing it into “refused” creates false certainty and can turn a temporary infrastructure fault into a permanent user-facing decision. Leaving the item pending supports a retry, an operational alert, or a safe recovery path while remaining truthful about what happened.

Keep adjacent boundaries aligned

The scan is only one part of the upload boundary. The storage layer still owns how opaque keys resolve to files, including protection against paths escaping the intended root. The scanner should use that existing resolver rather than copying path logic into a second component.

That avoids a subtle split-brain problem: storage accepts one interpretation of a key while scanning uses another. Security checks are strongest when every stage inspects the same bytes through the same trusted boundary.

Tests should reflect those boundaries too. Pure verdict mapping can be tested with ordinary inputs, but the liveness question deserves at least one test against the real host integration where the platform permits it. A mock can prove that our code handles the answer we programmed the mock to return. It cannot prove that the downstream engine is actually answering.

Useful tests include clean content, blocked-result ranges, an unavailable provider, missing bytes, and traversal attempts. Together they exercise the difference between a positive verdict, an operational failure, and an invalid storage request.

A practical review checklist

When reviewing a security or reliability integration, I now ask:

What observable behaviour proves the downstream capability is alive?
Are we checking a transport, a library, or the outcome we actually need?
Can the dependency fail after startup, and is it checked again at use time?
Does failure disable the risky capability or quietly weaken it?
Are positive security verdicts kept distinct from operational errors?
Does the test suite cross the real boundary that a mock would hide?

The broader lesson is simple: successful plumbing is not the same as successful protection. Trust the capability only after it demonstrates the behaviour your application depends on—and keep uncertainty visible when it cannot.

A Green Local Test Can Hide a Broken Project Graph

Ivan Rossouw — Wed, 16 Sep 2026 05:55:06 +0000

“The tests pass on my machine” is often treated as a testing problem. Sometimes it is really a dependency-graph problem.

Consider a browser application that contains a small deterministic rule: given one origin, derive another related origin. The rule has no UI state, network access, storage, or framework lifecycle. It deserves focused unit tests. The quickest route appears to be adding a project reference from the test project to the browser application and calling the rule directly.

A plain local test run can make that choice look correct. Compilation succeeds, the assertions pass, and the change feels complete. Then CI evaluates the same test project with different SDK properties and fails before test discovery. The failure is not in the rule. It comes from importing the application head and all the build behavior attached to it.

A project reference imports more than types

We often read a project reference as “this assembly may use those classes.” In SDK-style .NET builds, it also joins build graphs, targets, workloads, generated assets, and property-sensitive behavior.

An executable browser project is not just another class library. It may bring web-asset processing and browser-specific targets. A test project that references it now participates in enough of that build pipeline for CI properties to matter.

Imagine that CI disables web-asset work while compiling test projects. That may be a sensible estate-wide convention for ordinary tests. Once a test imports a browser head, however, the browser SDK can expect targets or tasks that the reduced test build does not provide. Evaluation fails before the runner reaches a single assertion.

The local green run and the CI failure are therefore compatible facts. They exercised different build contracts.

Do not make the pipeline absorb a bad edge

The immediate reaction might be to special-case the workflow: enable the missing feature for this test project, remove the shared flags, or create a new CI branch for the exception.

That can make the build green while preserving the architectural problem. A test project still depends on an executable application head only to reach a pure rule. Every future change to that head can now expand the test project’s build surface.

A better question is: what is the smallest dependency that the test actually needs?

In this case, it needs the deterministic mapping rule, not the application host. Moving that rule behind an existing neutral library boundary lets both the browser application and the test project depend inward. The invalid application reference disappears, and the graph gains no replacement edge because both consumers already reference the neutral library.

That is a small refactor with a useful architectural effect: the test compiles against the capability it exercises rather than the executable that happened to contain it.

The neutral seam is a trade-off, not a slogan

“Move it to shared” can become a dumping-ground strategy. A neutral library should not accumulate unrelated helpers simply because tests can reach it.

The placement here is deliberately narrower. The rule sits beside the abstraction used by its only application consumer, in a library already shared by the two relevant projects. Its dependencies remain simple, and the compromise is documented.

The documentation matters. It should explain why the apparently more natural location is currently invalid, why the selected seam is acceptable, and what future condition should trigger another move. For example, if the application head later gains its own compatible test project, the rule may be able to return to the feature boundary without weakening test coverage.

This is not architectural purity. It is an explicit, reversible decision.

Reproduce the build contract that failed

After changing the graph, rerun more than the convenient local command. Use the properties that exposed the failure.

A focused verification sequence is:

Confirm the test project no longer references the executable head.
Confirm both consumers already reference the neutral library.
Run the focused behavior tests.
Build or test with the same SDK properties CI supplies.
Check that no unrelated project edge or asset requirement appeared.

The point is not to mimic every pipeline detail locally. It is to reproduce the part of the build contract relevant to the failure. A bare test run proves behavior under default properties; it does not prove compatibility with a property-sensitive CI graph.

Review the graph before reviewing the assertion

When a test needs code from an executable head, pause before adding the reference. Ask:

Is the code actually coupled to the host, or is it a pure rule trapped there?
Will this reference import browser, web, desktop, or mobile SDK targets?
Do local and CI builds use the same relevant properties?
Is there an existing inward-facing seam both projects already depend on?
If the new location is a compromise, is its exit condition recorded?

This lesson applies beyond browser applications. Desktop heads, mobile apps, migration executables, worker hosts, and deployment projects can all carry build behavior that ordinary libraries do not.

The durable fix is often not another pipeline exception. It is a smaller, more truthful dependency: put the deterministic rule where its consumers can reach it without importing an executable world they do not need.