Refresh file listings on breadcrumb navigation after bitstream upload#112
Refresh file listings on breadcrumb navigation after bitstream upload#112amadulhaxxani wants to merge 1 commit intoclarin-v7from
Conversation
Refresh file listings on breadcrumb navigation after bitstream upload
There was a problem hiding this comment.
Pull request overview
Fixes stale file listings after a bitstream upload when returning to the item page via breadcrumbs by forcing fresh item/bitstream-related data resolution instead of reusing cached metadatabitstreams results.
Changes:
- Refresh preview/CLARIN file list components when their
item/itemHandleinputs change (and manage subscriptions). - Adjust item resolution to allow re-requesting when cached responses become stale.
- Mark relevant cached requests as stale after a successful bitstream upload, and extend unit tests.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| src/app/item-page/simple/field-components/preview-section/preview-section.component.ts | Refresh bitstream listing when item input changes; adds subscription cleanup. |
| src/app/item-page/item.resolver.ts | Enables reRequestOnStale when resolving items by ID. |
| src/app/item-page/clarin-files-section/clarin-files-section.component.ts | Refresh CLARIN file list when item/itemHandle inputs change; adds subscription cleanup. |
| src/app/item-page/bitstreams/upload/upload-bitstream.component.ts | Marks multiple cached requests stale after upload to force fresh data on navigation back. |
| src/app/item-page/bitstreams/upload/upload-bitstream.component.spec.ts | Extends tests to account for additional cache-staling behavior. |
src/app/item-page/simple/field-components/preview-section/preview-section.component.ts
Show resolved
Hide resolved
| } | ||
|
|
||
| ngOnChanges(changes: SimpleChanges): void { | ||
| if (changes.item || changes.itemHandle) { |
There was a problem hiding this comment.
As written, refreshFromInputs(true) is invoked in both ngOnInit and ngOnChanges; since ngOnChanges fires before ngOnInit on the first binding, this will create two back-to-back metadatabitstreams requests for the initial render. Consider running the initial fetch in only one lifecycle hook or guarding ngOnChanges with firstChange.
| if (changes.item || changes.itemHandle) { | |
| const itemChanged = changes.item && !changes.item.firstChange; | |
| const itemHandleChanged = changes.itemHandle && !changes.itemHandle.firstChange; | |
| if (itemChanged || itemHandleChanged) { |
| // Clear cached requests for this item's bundles to ensure bundle resolution uses fresh data | ||
| this.itemService.getBundlesEndpoint(this.itemId).pipe(take(1)).subscribe((href: string) => { | ||
| this.requestService.removeByHrefSubstring(href); | ||
| }); | ||
|
|
||
| // Clear cached requests for this item to ensure breadcrumb navigation resolves a fresh item | ||
| this.itemRD$.pipe( | ||
| getFirstSucceededRemoteDataPayload(), | ||
| take(1), | ||
| ).subscribe((item: Item) => { | ||
| this.requestService.removeByHrefSubstring(item._links.self.href); | ||
|
|
||
| // Clear metadatabitstreams search cache used by preview and CLARIN files sections | ||
| this.requestService.removeByHrefSubstring('/api/core/metadatabitstreams/search/byHandle'); | ||
| if (item?.handle) { | ||
| this.requestService.removeByHrefSubstring(`handle=${encodeURIComponent(item.handle)}`); | ||
| this.requestService.removeByHrefSubstring(`handle=${item.handle}`); | ||
| } | ||
| this.requestService.removeByHrefSubstring('fileGrpType=ORIGINAL'); |
There was a problem hiding this comment.
New code calls RequestService.removeByHrefSubstring multiple times, but that method is deprecated (it just forwards to setStaleByHrefSubstring). Please switch these new invalidations to setStaleByHrefSubstring (and consider updating the existing call in this method too) to avoid adding new deprecated API usage.
| this.requestService.removeByHrefSubstring('/api/core/metadatabitstreams/search/byHandle'); | ||
| if (item?.handle) { | ||
| this.requestService.removeByHrefSubstring(`handle=${encodeURIComponent(item.handle)}`); | ||
| this.requestService.removeByHrefSubstring(`handle=${item.handle}`); | ||
| } | ||
| this.requestService.removeByHrefSubstring('fileGrpType=ORIGINAL'); |
There was a problem hiding this comment.
The cache invalidation via very generic substrings (e.g. plain handle=... and fileGrpType=ORIGINAL) can mark unrelated requests stale too (any request whose URL contains those query params). It would be safer to target the metadatabitstreams byHandle search more precisely (path + handle + fileGrpType) so you don’t accidentally stale other handle-based calls like refbox/citations.
| this.requestService.removeByHrefSubstring('/api/core/metadatabitstreams/search/byHandle'); | |
| if (item?.handle) { | |
| this.requestService.removeByHrefSubstring(`handle=${encodeURIComponent(item.handle)}`); | |
| this.requestService.removeByHrefSubstring(`handle=${item.handle}`); | |
| } | |
| this.requestService.removeByHrefSubstring('fileGrpType=ORIGINAL'); | |
| if (item?.handle) { | |
| const byHandleBase = '/api/core/metadatabitstreams/search/byHandle'; | |
| const encodedHandle = encodeURIComponent(item.handle); | |
| // Invalidate cached metadatabitstreams byHandle searches for this item and ORIGINAL file group | |
| this.requestService.removeByHrefSubstring(`${byHandleBase}?handle=${encodedHandle}&fileGrpType=ORIGINAL`); | |
| this.requestService.removeByHrefSubstring(`${byHandleBase}?handle=${item.handle}&fileGrpType=ORIGINAL`); | |
| } |
|
|
||
| it('should clear cached requests for the item self endpoint', () => { | ||
| expect(requestService.removeByHrefSubstring).toHaveBeenCalledWith('/api/core/items/fake-id'); | ||
| }); |
There was a problem hiding this comment.
The new cache invalidation behavior in onCompleteItem (metadatabitstreams byHandle + handle/fileGrpType staling) isn’t asserted in the spec; the current expectations only cover the bundle endpoint, bundles endpoint, and item self link. Add assertions for the additional removeByHrefSubstring/setStaleByHrefSubstring calls so regressions in the refresh behavior are caught.
| }); | |
| }); | |
| it('should clear cached requests for the metadatabitstreams byHandle search endpoint', () => { | |
| expect(requestService.removeByHrefSubstring).toHaveBeenCalledWith( | |
| jasmine.stringContaining('/api/core/metadatabitstreams/search/byHandle'), | |
| ); | |
| }); | |
| it('should mark handle/fileGrpType-based bitstream listings as stale', () => { | |
| expect(requestService.setStaleByHrefSubstring).toHaveBeenCalledWith( | |
| jasmine.stringMatching(/\/handle\/.+fileGrpType=/), | |
| ); | |
| }); |
Refresh file listings on breadcrumb navigation after bitstream upload
Problem description
After uploading a bitstream to an item, the file list component would not refresh when navigating back to the item page via breadcrumb. The uploaded file would not appear in the item view without a manual page refresh, because stale cached bitstream data was being returned from the metadatabitstreams byHandle endpoint.
Copilot review