@farukada/aws-langgraph-dynamodb-ts 1.0.0-rc.1 → 1.0.0-rc.2

package/dist/store/internal/validation.js

@@ -1,51 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.validatePaging = validatePaging;
-exports.validateNamespace = validateNamespace;
-exports.validateKey = validateKey;
-exports.validateStoreKey = validateStoreKey;
-exports.validateMaxDepth = validateMaxDepth;
-const constants_1 = require("../../shared/constants");
-const errors_1 = require("../../shared/errors/errors");
-const primitives_1 = require("../../shared/validation/primitives");
-const keys_1 = require("./keys");
-/** Validate search/listNamespaces paging is non-negative integers. */
-function validatePaging(offset, limit) {
-    (0, primitives_1.validateInteger)(offset, 'offset', { min: 0 });
-    (0, primitives_1.validateInteger)(limit, 'limit', { min: 0 });
-}
-/** Validate the namespace is non-empty and each element is a valid, ≤256-byte identifier. */
-function validateNamespace(namespace) {
-    (0, primitives_1.validateNonEmptyArray)(namespace, 'namespace');
-    for (const element of namespace) {
-        (0, primitives_1.validateIdentifier)(element, keys_1.NAMESPACE_SEPARATOR, 'namespace element', constants_1.MAX_KEY_SEGMENT_BYTES);
-    }
-}
-/** Validate an item key is a non-blank, separator- and control-char-free, ≤256-byte string. */
-function validateKey(key) {
-    (0, primitives_1.validateIdentifier)(key, keys_1.NAMESPACE_SEPARATOR, 'key', constants_1.MAX_KEY_SEGMENT_BYTES);
-}
-/**
- * Validate a namespace/key pair as the item address it becomes: each segment
- * on its own, then the sort key they compose, which DynamoDB caps at 1024
- * bytes regardless of how short the individual segments are.
- */
-function validateStoreKey(namespace, key) {
-    validateNamespace(namespace);
-    validateKey(key);
-    const bytes = Buffer.byteLength((0, keys_1.sortKey)(namespace, key), 'utf8');
-    if (bytes > constants_1.MAX_SORT_KEY_BYTES) {
-        throw new errors_1.ValidationError(`namespace and key compose a ${bytes}-byte sort key; DynamoDB caps sort keys at ` +
-            `${constants_1.MAX_SORT_KEY_BYTES} bytes`, 'sortKey');
-    }
-}
-/**
- * Validate an optional namespace depth cap. Left unchecked, a negative value
- * silently inverted truncation via `Array.prototype.slice(0, -n)`, which drops
- * the *last* n elements rather than erroring.
- */
-function validateMaxDepth(maxDepth) {
-    if (maxDepth === undefined)
-        return;
-    (0, primitives_1.validateInteger)(maxDepth, 'maxDepth', { min: 1 });
-}

package/dist/store/internal/write-verify.d.ts

@@ -1,42 +0,0 @@
-import type { StoreContext } from './setup';
-/** True when `error` is a {@link RetryExhaustedError} — by name, not `instanceof` (banned repo-wide). */
-export declare function isRetryExhausted(error: Error): boolean;
-/**
- * True when the row is confirmed absent — used to resolve an ambiguous
- * retry-exhausted *delete*, where the delete may well have landed server-side
- * and only its acknowledgement was lost. Only the partition key is projected:
- * existence is the whole question. A failure reading this is not treated as
- * confirmation, which is fail-safe here: the caller only rethrows, and nothing
- * is deleted on the strength of a `false`.
- */
-export declare function rowIsAbsent(context: StoreContext, key: {
-    PK: string;
-    SK: string;
-}): Promise<boolean>;
-/** What a post-failure verification read could establish about a write. */
-export type WriteVerdict = 'landed' | 'not-landed' | 'unverified';
-/**
- * Read `record`'s row back to establish what an ambiguous write actually did,
- * comparing the row's revision with the one this write carried. Every put
- * stamps a fresh per-call `rev`, so the comparison works for inline and
- * offloaded records alike.
- *
- * - `'landed'`: the row holds this write's `rev`, so it committed server-side
- *   and only its acknowledgement was lost.
- * - `'not-landed'`: the row was read and holds something else, or nothing —
- *   or the record carries no `rev` to compare — so this call's own upload, if
- *   any, is dead and safe to delete.
- * - `'unverified'`: the read itself failed, so nothing is established.
- *
- * The third answer used to be folded into the second as a plain `false`, which
- * made a partition that blocked both the put and this read delete the object a
- * possibly-live row points at — permanently breaking every later read of that
- * item. Only a *confirmed* non-commit may delete the new upload: leaking one
- * object (reclaimed by `ensureS3LifecycleRule`) is recoverable, stranding a
- * live row is not.
- */
-export declare function verifyWriteLanded(context: StoreContext, record: {
-    PK: string;
-    SK: string;
-    rev?: string;
-}): Promise<WriteVerdict>;

package/dist/store/internal/write-verify.js

@@ -1,71 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.isRetryExhausted = isRetryExhausted;
-exports.rowIsAbsent = rowIsAbsent;
-exports.verifyWriteLanded = verifyWriteLanded;
-const conditional_put_1 = require("../../shared/dynamodb/conditional-put");
-const retry_1 = require("../../shared/dynamodb/retry");
-/** True when `error` is a {@link RetryExhaustedError} — by name, not `instanceof` (banned repo-wide). */
-function isRetryExhausted(error) {
-    return error.name === 'RetryExhaustedError';
-}
-/**
- * True when the row is confirmed absent — used to resolve an ambiguous
- * retry-exhausted *delete*, where the delete may well have landed server-side
- * and only its acknowledgement was lost. Only the partition key is projected:
- * existence is the whole question. A failure reading this is not treated as
- * confirmation, which is fail-safe here: the caller only rethrows, and nothing
- * is deleted on the strength of a `false`.
- */
-async function rowIsAbsent(context, key) {
-    try {
-        const result = await (0, retry_1.withDynamoDBRetry)(() => context.client.get({
-            TableName: context.tableName,
-            Key: key,
-            ConsistentRead: true,
-            ProjectionExpression: '#pk',
-            ExpressionAttributeNames: { '#pk': 'PK' },
-        }), context.retry);
-        return result.Item === undefined;
-    }
-    catch {
-        return false;
-    }
-}
-/**
- * Read `record`'s row back to establish what an ambiguous write actually did,
- * comparing the row's revision with the one this write carried. Every put
- * stamps a fresh per-call `rev`, so the comparison works for inline and
- * offloaded records alike.
- *
- * - `'landed'`: the row holds this write's `rev`, so it committed server-side
- *   and only its acknowledgement was lost.
- * - `'not-landed'`: the row was read and holds something else, or nothing —
- *   or the record carries no `rev` to compare — so this call's own upload, if
- *   any, is dead and safe to delete.
- * - `'unverified'`: the read itself failed, so nothing is established.
- *
- * The third answer used to be folded into the second as a plain `false`, which
- * made a partition that blocked both the put and this read delete the object a
- * possibly-live row points at — permanently breaking every later read of that
- * item. Only a *confirmed* non-commit may delete the new upload: leaking one
- * object (reclaimed by `ensureS3LifecycleRule`) is recoverable, stranding a
- * live row is not.
- */
-async function verifyWriteLanded(context, record) {
-    if (record.rev === undefined)
-        return 'not-landed';
-    try {
-        const result = await (0, retry_1.withDynamoDBRetry)(() => context.client.get({
-            TableName: context.tableName,
-            Key: { PK: record.PK, SK: record.SK },
-            ConsistentRead: true,
-            ProjectionExpression: '#r',
-            ExpressionAttributeNames: { '#r': conditional_put_1.REVISION_ATTRIBUTE },
-        }), context.retry);
-        return result.Item?.[conditional_put_1.REVISION_ATTRIBUTE] === record.rev ? 'landed' : 'not-landed';
-    }
-    catch {
-        return 'unverified';
-    }
-}