fix: argument forwarding in vault.listObjects

[rodobre]

Related issue

#1516

Description

vault.listObjects accepts PaginationOptions but only forwards after and limit to the API. The before and order parameters are silently ignored, making it impossible to paginate backwards or control sort order through the SDK.

This adds the missing before and order query parameters to the vault listObjects method, matching how other endpoints (e.g. sso.listConnections, organizations.listOrganizations) already handle pagination.

Changes

• Forward options.before as the before query parameter
• Forward options.order as the order query parameter

Before

const url = new URL('/vault/v1/kv', this.workos.baseURL);
if (options?.after) {
url.searchParams.set('after', options.after);
}
if (options?.limit) {
url.searchParams.set('limit', options.limit.toString());
}
// before and order never reach the API

Documentation

No documentation change is required.

[greptile-apps]

Greptile Summary

This PR fixes a bug in vault.listObjects where before and order pagination parameters accepted by the method's PaginationOptions argument were silently dropped and never forwarded to the API. The fix mirrors the approach already used by after and limit in the same method, and matches the pattern seen in the shared serializePaginationOptions helper and other SDK endpoints.

• Root cause fixed: before and order are now appended as URL query parameters, consistent with how after and limit are handled.
• Null/undefined safety: The truthy guard (if (options?.before)) correctly suppresses null and undefined values, matching the existing after behaviour and the shared serializer.
• No breaking changes: Existing callers that omit these options are unaffected.
• Test gap: vault.spec.ts has no test cases exercising the newly forwarded parameters; adding coverage would prevent regressions.

Confidence Score: 5/5

• This PR is safe to merge — it is a minimal, additive bug fix with no breaking changes.
• The change is two short, symmetric blocks that follow exactly the same pattern as the pre-existing after and limit handling in the same function. The PaginationOptions interface already declares before and order, so no type changes are needed. The only gap is missing unit-test coverage for the new parameters.
• No files require special attention; src/vault/vault.spec.ts would benefit from additional test cases for the new parameters.

Important Files Changed

Filename	Overview
src/vault/vault.ts	Adds before and order query parameters to listObjects, fixing silent omission. Implementation is consistent with the existing after/limit pattern and the shared serializePaginationOptions helper.

Sequence Diagram

sequenceDiagram
    participant Caller
    participant vault.listObjects
    participant WorkOS API

    Caller->>vault.listObjects: listObjects({ before, after, limit, order })
    Note over vault.listObjects: Build URL /vault/v1/kv
    vault.listObjects->>vault.listObjects: set ?before= (new)
    vault.listObjects->>vault.listObjects: set ?after=
    vault.listObjects->>vault.listObjects: set ?limit=
    vault.listObjects->>vault.listObjects: set ?order= (new)
    vault.listObjects->>WorkOS API: GET /vault/v1/kv?before=&after=&limit=&order=
    WorkOS API-->>vault.listObjects: ListResponse<ObjectDigestResponse>
    vault.listObjects-->>Caller: List<ObjectDigest>

Loading

_{Last reviewed commit: 8281d91}

[greptile-apps]

Missing test coverage for new parameters

The existing listObjects test suite only covers the no-options case. The newly forwarded before and order parameters have no corresponding test cases to verify they are correctly appended as query parameters. Consider adding tests similar to:

it('forwards before and order query parameters', async () => {
  fetchOnce({ data: [], list_metadata: { after: null, before: null } });
  await workos.vault.listObjects({ before: 'cursor123', order: 'asc' });
  expect(fetchURL()).toContain('before=cursor123');
  expect(fetchURL()).toContain('order=asc');
});