corsairdev/corsair

Two problems in packages/jira/endpoints/issues.ts. 1. issues.search can't page past the first page. It calls GET /rest/api/3/search/jql and passes startAt: input.start_at (line 172). That endpoint doesn't have startAt. It uses token pagination: the response includes nextPageToken and isLast, and you pass nextPageToken to get the next page. Right now start_at is ignored and every call returns page one. The response schema also drops nextPageToken, so callers can't even get the token. Docs: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-search/#api-rest-api-3-search-jql-get 2. Synced issues get the wrong createdAt. get, search and bulkFetch upsert issues with createdAt: new Date() (lines 90, 194, 377), so every sync overwrites the real creation date with "now". Jira returns the real value in fields.created. Fix: In IssuesSearchInputSchema, replace start_at with next_page_token, and add nextPageToken / isLast to the response schema. Send nextPageToken only wh

What happens: issues.delete, mergeRequests.delete and projects.delete delete the resource on GitLab, but the synced rows stay in the local DB forever. Why: deleteIssue (packages/gitlab/endpoints/issues.ts:108-126), deleteMr (merge-requests.ts:118) and deleteProject (projects.ts:107) send the DELETE and log the event, but never touch ctx.db. Every other plugin with a DB cleans up after a delete. It's not a one-liner because the delete input is project_id + iid, while rows are stored by the global id. These are different numbers. For example, GET /projects/278964/issues/632417 returns id: 205640274. Also, project_id can be either a numeric id or a path like gitlab-org/gitlab. So you have to find the row by iid (+ project) first and then delete it. Docs: https://docs.gitlab.com/api/issues/#delete-an-issue https://docs.gitlab.com/api/merge_requests/#delete-a-merge-request https://docs.gitlab.com/api/projects/#delete-a-project Fix: after the DELETE succeeds, look up the mirrored row by ii

What happens: deleting a folder with files.delete leaves the folder row in the local DB. Deleting a file works fine. Why: deleteFile in packages/dropbox/endpoints/files.ts:45-76 only cleans up when the returned metadata is a file: if (meta['.tag'] === 'file') { /2/files/delete_v2 works on folders too, and returns metadata with .tag: 'folder' in that case. Folders are stored in ctx.db.folders, which is never touched here. Docs: https://www.dropbox.com/developers/documentation/http/documentation#files-delete Fix: add the folder branch, so .tag === 'folder' calls ctx.db.folders.deleteByEntityId(meta.id). Also make the guard check ctx.db.files || ctx.db.folders so it doesn't skip folders when only that store exists.

What happens: the AgentQL cache misses on requests that are exactly the same but have their params in a different key order. { mode: 'fast', wait_for: 1 } and { wait_for: 1, mode: 'fast' } produce different cache keys, so the second call hits the API again. Why: buildQueryDataCacheKey and buildQueryDocumentCacheKey in packages/agentql/endpoints/cache-keys.ts (lines 21 and 36) hash the raw JSON.stringify(normalized). JSON.stringify keeps insertion order, so the key depends on how the caller built the object. That includes nested ones like the proxy config. Fix: sort object keys recursively before stringifying. Add a small cache-keys.test.ts that checks two key orders give the same hash and that different values still give different hashes.

What happens: a datetime without a timezone, like from: '2024-06-01T12:00:00', gets shifted by the server's UTC offset before it's sent to Ambee. On a machine in IST it goes out as 2024-06-01 06:30:00. On a UTC server it's correct, so the bug depends on where you deploy. Why: toAmbeeTimestamp in packages/ambee/client.ts:105 does new Date(value) and then formats it in UTC. JS parses an ISO datetime with no zone as local time, so the local offset leaks into the result. Ambee's history endpoints take from/to as YYYY-MM-DD hh:mm:ss, which has no zone at all. So the input should be treated as UTC, which is also what the existing formatting assumes. Docs: https://docs.ambeedata.com/apis/weather Fix: if the value has a T and no Z or ±hh:mm suffix, append Z before parsing. Repro test: run with TZ=Asia/Kolkata and check that toAmbeeTimestamp('2024-06-01T12:00:00') returns 2024-06-01 12:00:00.