Redundant TTL check after readStore already prunes expired entries

readStore calls pruneExpired(value.uploads, Date.now(), ttlMs) before returning, which removes any entry where nowMs - record.createdAt > ttlMs. Since all records returned in store.uploads have already passed that filter, this subsequent check (Date.now() - record.createdAt > ttlMs) at lines 186–188 can never be true in practice — the only scenario where it would fire is if the TTL expires in the nanoseconds between readStore's Date.now() call and this one, which requires a TTL of ~0ms. The code can be simplified:

This is a comment left during a code review.
Path: extensions/msteams/src/pending-uploads-fs.ts
Line: 186-188

Comment:
**Redundant TTL check after `readStore` already prunes expired entries**

`readStore` calls `pruneExpired(value.uploads, Date.now(), ttlMs)` before returning, which removes any entry where `nowMs - record.createdAt > ttlMs`. Since all records returned in `store.uploads` have already passed that filter, this subsequent check (`Date.now() - record.createdAt > ttlMs`) at lines 186–188 can never be `true` in practice — the only scenario where it would fire is if the TTL expires in the nanoseconds between `readStore`'s `Date.now()` call and this one, which requires a TTL of ~0ms. The code can be simplified:

```suggestion
  return recordToUpload(record);
```

How can I resolve this? If you propose a fix, please make it concise.

Treat FS activity-id persistence as best effort

This call runs after the FileConsent card has already been sent, so an I/O failure here (e.g., disk full, permission issue, transient lock error) turns a successful send into a thrown error. In that scenario users see the command fail and may retry, creating duplicate consent cards, even though the pending upload record already exists and the accept flow can still work. The FS activity-id update should be non-fatal (log and continue) rather than failing sendMessageMSTeams.

Useful? React with 👍 / 👎.

Make FS pending-upload cleanup non-fatal in invoke handler

removePendingUploadFs is awaited inside finally, so a cleanup write failure can reject the invoke handler even after the file upload already succeeded. In environments with intermittent FS issues this can surface as a failed invoke/possible retry path and duplicate side effects, despite successful upload work. Cleanup should be best-effort (catch/log) so storage errors do not break the user-facing consent completion flow.

Useful? React with 👍 / 👎.

Roll back in-memory pending upload on FS write failure

prepareFileConsentActivityFs creates the in-memory pending entry before awaiting the filesystem mirror write, so any storePendingUploadFs error (disk full, permissions, lock/write failure) throws after the large buffer has already been retained in pending-uploads.ts. In long-lived paths that call sendMessageMSTeams (for example outbound/action uploads), repeated failures can accumulate multiple large buffers for the full TTL and cause avoidable memory pressure; this should remove the in-memory entry on FS failure (or write FS first with a generated id).

Useful? React with 👍 / 👎.

Validate upload records before pruning the FS store

isValidStore only verifies that uploads is an object, but pruneExpired assumes each entry has a record shape with createdAt; a malformed entry like {"uploads":{"x":null}} will throw when record.createdAt is accessed and break consent-store reads/writes until manual cleanup. Since this module is intended to tolerate malformed store files, it should also validate or defensively skip invalid per-upload entries.

Useful? React with 👍 / 👎.

Persist TTL pruning when expired FS upload is read

When an entry is expired, getPendingUploadFs returns undefined but never writes the deletion back, so expired base64 file payloads can remain in msteams-pending-uploads.json indefinitely if no later write happens. That breaks the intended 5-minute retention behavior for abandoned consent cards and can keep sensitive file bytes on disk much longer than expected; expired reads should trigger a locked rewrite/removal.

Useful? React with 👍 / 👎.