Project

General

Profile

Actions

Bug #18484

closed

Direct links to Collections are retrieving the full manifest_text for no reason

Added by Daniel Kutyła over 2 years ago. Updated over 2 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
Workbench2
Target version:
Story points:
-
Release relationship:
Auto

Description

The workbench2 has been optimised to not retrieve the manifest_text from collections since the manifest is not used by the Workbench2 and to avoid unnecessary load. It seems that this only works when navigating to a collection within the workbench but is not working when opening a collection url.


Subtasks 1 (0 open1 closed)

Task #18497: Review 18484-collection-manifest-fixResolvedStephen Smith12/01/2021Actions

Related issues

Related to Arvados Workbench 2 - Bug #18584: Collection's "Make a copy" action failsResolvedLucas Di Pentima12/14/2021Actions
Related to Arvados Workbench 2 - Bug #18966: Requesting a non-visible collection UUID shows a blank pageResolvedLucas Di Pentima04/04/2022Actions
Actions #1

Updated by Lucas Di Pentima over 2 years ago

  • Release set to 48
  • Target version set to 2021-12-08 sprint
  • Status changed from New to In Progress
Actions #2

Updated by Lucas Di Pentima over 2 years ago

I have been studying which would be the best way to avoid getting the manifest_text field from the collection's GET requests.

We already support the select param to pass an array of field names to be included on the request. The problem I'm seeing is that passing a hardcoded array of strings isn't future-proof because we could be adding new fields to the collection model that would require updating the code on wb2.

I've been trying to find a dynamic way of doing this on TypeScript, but I think there's no good way currently, as interfaces & types exist only in TS, so no type-reflection can be made once the app is compiled for production.

The only two options I'm seeing (besides adding a exclude param to the backend) are:

  • Hard-code the field names array
  • Use the discovery document to build the array on the app's bootup procedure.

I'm not sure if there're significant downsides to the 2nd option, but it would be my preferred choice.

Actions #3

Updated by Lucas Di Pentima over 2 years ago

From chat: Peter suggested using a "list" request with filters so that manifest_text fields won't be received.

Actions #4

Updated by Lucas Di Pentima over 2 years ago

Updates at arvados-workbench2|34e3489e - branch 18484-collection-manifest-fix
Test run: developer-tests-workbench2: #521

  • Makes CollectionService.get() to use the list request under the hood, with a uuid filter.
  • Adds test.
Actions #5

Updated by Lucas Di Pentima over 2 years ago

Updates at arvados-workbench2|30ef6aaa
Test run: developer-tests-workbench2: #522

  • Adds "include_old_versions: true" param & select support to CollectionService.get()
  • Fixes related code so that the manifest_text field is requested where needed.
  • Adds test.
Actions #6

Updated by Stephen Smith over 2 years ago

Lgtm

Actions #7

Updated by Lucas Di Pentima over 2 years ago

  • Status changed from In Progress to Resolved
Actions #8

Updated by Lucas Di Pentima over 2 years ago

  • Related to Bug #18584: Collection's "Make a copy" action fails added
Actions #9

Updated by Lucas Di Pentima about 2 years ago

  • Related to Bug #18966: Requesting a non-visible collection UUID shows a blank page added
Actions

Also available in: Atom PDF