[sync] chore: upgrade node runtime to 24.19.0 and @types/node to 24.13.2 - #3638
[sync] chore: upgrade node runtime to 24.19.0 and @types/node to 24.13.2#3638tea-artist wants to merge 1 commit into
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a6fa6328f8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (isHeic(mimetype)) { | ||
| // Sharp cannot decode HEVC, so height is unknown at upload time and the | ||
| // whole file goes through the WASM decoder instead of cropTableImage. |
There was a problem hiding this comment.
When the S3 storage adapter is used, this branch is never reached for the HEIC files it is intended to support: AttachmentsService.notify first calls S3Storage.getObjectMeta, which sends every image/* stream through sharp().metadata() and converts Sharp's HEVC failure into a validation error (plugins/s3.ts:311-350). Local and MinIO tolerate missing dimensions, but S3 rejects the upload before creating the attachment or queuing this processor. Detect HEIC in the S3 metadata path and return metadata without asking Sharp for dimensions so production S3-backed uploads can reach the WASM decoder.
Useful? React with 👍 / 👎.
| ({ lgThumbnailPath, smThumbnailPath } = | ||
| await this.attachmentsStorageService.uploadTableImageThumbnailsFromBuffer( | ||
| bucket, | ||
| path, | ||
| buffer, | ||
| imgHeight | ||
| )); |
There was a problem hiding this comment.
For a HEIC image whose height is at most 525px, uploadTableImageThumbnailsFromBuffer does not create an lg thumbnail (and at most 56px it creates neither size), because that helper only writes resized variants above its size thresholds. The processor then stores missing thumbnail paths, while record.service.ts:2144-2145 substitutes the original presigned HEIC URL for each missing image thumbnail; browsers without HEIC support therefore still show a broken image instead of the decoded PNG. Store the converted PNG itself for any missing thumbnail size, or avoid falling back to the original file for HEIC.
Useful? React with 👍 / 👎.
tea-artist
changed the title
a6fa632 to
f4a50e6
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f4a50e6804
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| return `/t/${resourceId}`; | ||
| // Resolve the template landing URL directly instead of redirecting | ||
| // through the /t permalink page (T6802). | ||
| return resolveTemplateRedirectUrl(prisma, resourceId); |
There was a problem hiding this comment.
Because getShortLink caches this resolved path for 60 seconds, updating a template's snapshot or publishInfo.defaultUrl can leave an active short link pointing at the previous snapshot base until the cache expires. TemplateOpenApiService currently clears only the template-permalink cache on those updates; that was sufficient while short links returned /t/:id, but this direct resolution bypasses that freshly invalidated permalink lookup and can produce a transient 404 after the old snapshot is deleted. Invalidate the template's short-link cache whenever its redirect target changes.
Useful? React with 👍 / 👎.
| if (baseShare.password) { | ||
| return `/share/${resourceId}/base`; |
There was a problem hiding this comment.
If this short link was resolved during the preceding 60 seconds, getShortLink returns its cached deep table/view path without re-evaluating this password branch after updateBaseShare adds a password. That sends unauthenticated visitors through the protected resource URL and exposes the base/table/view identifiers that this branch explicitly intends to hide before authentication; the base-share update path does not invalidate the short-link cache when the password changes. Clear the associated short-link cache whenever protection is added or removed.
Useful? React with 👍 / 👎.
tea-artist
changed the title
f4a50e6 to
2ee2008
Compare
tea-artist
changed the title
2ee2008 to
3489afd
Compare
Synced from teableio/teable-ee@bc69b8a Co-authored-by: Boris <boris2code@outlook.com> Co-authored-by: Pengap <penganpingprivte@gmail.com> Co-authored-by: nichenqin <nichenqin@hotmail.com>
tea-artist
changed the title
3489afd to
e2ff69c
Compare
1 participant
🔄 Automated sync from EE repository.
5 commit(s) synced since last sync.
Authors
Included commits
Latest source commit: teableio/teable-ee@bc69b8a
This PR was automatically created by the sync workflow.