/*!
 * Copyright (c) 2026 Interop Alliance. All rights reserved.
 */
/**
 * The `get` half of a {@link WasSyncPort}: resolves a resource's current master
 * state (for the 412 conflict re-read) from the CHANGES-FEED BODY. Wraps a
 * {@link WasSyncBasePort} (query + conditional writes) and adds the `get` the
 * conflict assembler needs, producing a full {@link WasSyncPort}.
 *
 * Why the feed body rather than a `GET` ETag header: the mutable-head model
 * settles a 412 by re-reading the resource's current `version` and comparing
 * payloads (LWW). A raw `GET` reads that `version` from the response's `etag`
 * header -- which a browser hides on a CROSS-ORIGIN response unless the server
 * sends `Access-Control-Expose-Headers: etag`. A server that does not expose it
 * would make a cross-origin re-read report `version: 0`, so the loser of a push
 * race would re-push forever with a stale `If-Match` and never converge. The
 * `changes` feed carries `version` (and `data`, `_deleted`, ...) in the JSON
 * BODY, which CORS never strips, so resolving the master from the feed is both
 * correct and origin-independent. Normal pull/push are unaffected (they already
 * read `version` from the feed body).
 */
import type { WasSyncBasePort, WasSyncPort } from './types.js';
/**
 * Wraps a base port with a `get` that resolves the master state from the changes
 * feed. `query`, `putContent`, `deleteContent`, and `putMeta` pass straight
 * through.
 *
 * A walk starts at the feed's origin, so resolving one resource pages past many
 * others. With a per-push-batch `cache` the walk memoizes every one of them, and
 * a row that finds a walk already running waits for it rather than starting a
 * second -- so a batch of k conflicting rows costs one feed scan instead of k
 * concurrent ones. Without a `cache` the behavior is exactly as before.
 *
 * @param base {WasSyncBasePort}
 * @returns {WasSyncPort}
 */
export declare function withFeedMasterRead(base: WasSyncBasePort): WasSyncPort;
//# sourceMappingURL=feedMasterPort.d.ts.map