The createMemoryStoreUpdatePoller function is missing JSDoc documentation. As this is an exported function that creates the custom poller, it should document its parameters, return value, and usage examples following Azure SDK guidelines for public APIs.

The buildRunningOperation function doesn't receive the user-provided options.abortSignal, which is needed for proper abort handling in sendPollRequest. Looking at the reference implementation in pollingHelpers.ts (lines 53-94), the abort signal from options is captured in the closure and used in the sendPollRequest method.

Without this, user abort signals won't properly cancel ongoing poll requests. The function signature should include options: CreateMemoryStoreUpdatePollerOptions as a parameter, and the sendPollRequest should handle options.abortSignal similar to the reference implementation.

@copilot open a new pull request to apply changes based on this feedback

When the status is "failed", the code only sets state.error if it doesn't already exist (if (!state.error)). However, it doesn't set state.result in the failure case. According to the LRO pattern, when an operation fails, the state should still be properly initialized. If a consumer expects state.result to always be defined when accessing it, this could cause issues.

Consider initializing state.result with a default value even in the failure case for consistency, or document that result will be undefined on failure.

LRO pattern says result should be populated only if status=completed, error should only be populated if status=failed. In this case, superseded_by should only be populated if status=superseded.

@copilot open a new pull request to apply changes based on this feedback

The check terminalUpdateStatuses.includes(parsed.status) will incorrectly mark "failed" status as succeeded. The terminalUpdateStatuses array includes "failed" (line 43), but the code already handles "failed" in the previous conditional (lines 111-118). This means if the check on line 111 is somehow bypassed or if there's a logic error, a "failed" status could incorrectly be treated as "succeeded".

The terminalUpdateStatuses array should only include non-error terminal statuses: ["completed", "superseded"].

@copilot open a new pull request to apply changes based on this feedback

The new public API types MemoryStoreUpdateOperationState and MemoryStoreUpdatePoller are marked as (undocumented) in the API extractor output. According to Azure SDK guidelines, all public APIs must be documented. These types need JSDoc comments in the source code (memoryStoreUpdatePoller.ts) to appear properly documented in the API surface.

The abort signal handling in sendPollRequest is incomplete compared to the reference implementation in pollingHelpers.ts. The reference implementation (lines 67-83) handles both the user-provided options.abortSignal and the poll-specific pollOptions?.abortSignal, while this implementation only handles pollOptions?.abortSignal. This means user abort signals from the initial createMemoryStoreUpdatePoller options won't be properly propagated to poll requests.

Suggestion: Add handling for the user-provided abort signal similar to the reference implementation:

const abortSignal = pollAbortController.signal;
if (options?.abortSignal?.aborted) {
  pollAbortController.abort();
} else if (pollOptions?.abortSignal?.aborted) {
  pollAbortController.abort();
} else if (!abortSignal.aborted) {
  options?.abortSignal?.addEventListener("abort", abortListener, {
    once: true,
  });
  pollOptions?.abortSignal?.addEventListener("abort", abortListener, {
    once: true,
  });
}

And in the finally block, remove both listeners.

@copilot open a new pull request to apply changes based on this feedback

The public API types MemoryStoreUpdateOperationState and MemoryStoreUpdatePoller are missing JSDoc documentation comments. According to Azure SDK guidelines, all public APIs should have clear documentation explaining their purpose and usage. This is especially important for these types as they introduce new extension properties (updateId, updateStatus, supersededBy) beyond the standard OperationState.

The CreateMemoryStoreUpdatePollerOptions interface is missing JSDoc documentation. This should document the purpose of each option, especially restoreFrom which is used for resuming a poller from a serialized state.

Can we override existing status property instead of defining a new updateStatus?

(Surprised by OperationState_2 name)

updateId and status are both required, if that is consistent with OperationState_2 design.

Can we override existing status property instead of defining a new updateStatus?

(Surprised by OperationState_2 name)

The reason for the OperationState name collision is that another "OperationState" is apparently being emitted from our TypeSpec, and that local OperationState roughly corresponds to the OperationStatus enum in core-lro/poller.

Can we override existing status property instead of defining a new updateStatus?

(Surprised by OperationState_2 name)

Are the responses from the service constrained to the OperationStatus strings? I'm seeing "queued" and "superseded" as possible return statuses, but those don't exist in the OperationStatus enums here

LRO pattern says result should be populated only if status=completed, error should only be populated if status=failed. In this case, superseded_by should only be populated if status=superseded.

terminal is the same as succeeded. It just means that we need to stop polling. Do we have to remap status to failed/succeeded/running? Or can we return the original values?

I'm not seeing "superseded" or "queued" as status values for OperationStatus in the core-lro/poller. What do you suggest?