Fix dataset URL display in workflow landings

[ahmedhamidawan]

Notice how the collection input value shows up in this workflow landing, but the dataset does not:

PR #19935 implemented this display. In the client, we currently expect the landings to have the structure based on the pydantic types defined in lib/galaxy/tool_util_models/parameters.py. And that is evidenced here:

https://github.com/galaxyproject/galaxy/blob/f0ebb7bab3e96e166b300982554c967bb46f8c46/client/src/components/Form/Elements/FormData/types.ts (some details in that commit message too)

Now, for this particular workflow landing, we have:

{
  ...,
  "request_state": {
    "Annotation GTF": {
      "class": "File",
      "filetype": "gtf",
      "location": "https://zenodo.org/records/14009320/files/Annotation%20GTF.gtf?download=1"
    },
    "Genome fasta": {
      "class": "File",
      "filetype": "fasta.gz",
      "location": "https://zenodo.org/records/14009320/files/Genome%20fasta.fasta.gz?download=1"
    },
    "Paired Collection": {
      "class": "Collection",
      "collection_type": "list:paired",
      "elements": [
        {
          "class": "Collection",
          "elements": [
            {
              "class": "File",
              "filetype": "fastqsanger",
              "identifier": "forward",
              "location": "https://zenodo.org/records/14009320/files/ERR018930_forward.fastqsanger.gz?download=1"
            },
            {
              "class": "File",
              "filetype": "fastqsanger",
              "identifier": "reverse",
              "location": "https://zenodo.org/records/14009320/files/ERR018930_reverse.fastqsanger.gz?download=1"
            }
          ],
          "identifier": "ERR018930",
          "type": "paired"
        },
        {
          "class": "Collection",
          "elements": [
            {
              "class": "File",
              "filetype": "fastqsanger",
              "identifier": "forward",
              "location": "https://zenodo.org/records/14009320/files/ERR1035492_forward.fastqsanger.gz?download=1"
            },
            {
              "class": "File",
              "filetype": "fastqsanger",
              "identifier": "reverse",
              "location": "https://zenodo.org/records/14009320/files/ERR1035492_reverse.fastqsanger.gz?download=1"
            }
          ],
          "identifier": "ERR1035492",
          "type": "paired"
        }
      ]
    }
  },
  ...
}

Displaying the "Paired Collection" collection input works well, because the client expects:

galaxy/client/src/components/Form/Elements/FormData/types.ts

Lines 43 to 49 in f0ebb7b

	interface DataUriCollection {
	class: "Collection";
	collection_type: string;
	elements: DataUriCollectionElement[];
	deferred?: boolean;
	name?: string | null;
	}

which matches the backend response structure.

But the datasets (File) inputs are not working (displaying in the client). The client schema expects:

galaxy/client/src/components/Form/Elements/FormData/types.ts

Lines 11 to 30 in f0ebb7b

	interface BaseDataUri {
	location: string;
	name?: string | null;
	ext: string;
	dbkey?: string;
	deferred?: boolean;
	created_from_basename?: string | null;
	info?: string | null;
	hashes?: DatasetHash[] | null;
	space_to_tab?: boolean;
	to_posix_lines?: boolean;
	}
	interface DataUriData extends BaseDataUri {
	src: "url";
	}
	interface DataUriFile extends BaseDataUri {
	class: "File";
	}

FormDataUri.vue checks to see if it isDataUriFile which seems to be failing, and I see why. If we look at these methods:

galaxy/client/src/components/Form/Elements/FormData/types.ts

Lines 55 to 65 in f0ebb7b

	function isBaseDataUri(item: object): item is BaseDataUri {
	return Boolean(item) && "location" in item && "ext" in item;
	}
	export function isDataUriData(item: object): item is DataUriData {
	return isBaseDataUri(item) && "src" in item && item.src === "url";
	}
	export function isDataUriFile(item: object): item is DataUriFile {
	return isBaseDataUri(item) && "class" in item && item.class === "File";
	}

isBaseDataUri is the one that fails, as the backend is returning filetype instead of ext (what we expect here).

We had a discussion about this here: #19935 (comment), and it is why I changed filetype to ext in BaseDataUri.

Is it ok if I revert the ext to filetype then, since that is the key that workflow landings have?

[ahmedhamidawan]

Oh, and another request that we have is to also allow for workflow landing inputs to be toggled as typical populate-able workflow inputs in the main run form. We can use a similar functionality as the workflow rerun form which lets the user know that they are modifying (or in this case, switching from) original/landing values.

[mvdbeek]

Is it ok if I revert the ext to filetype then, since that is the key that workflow landings have?

that's not generally true. the quick fix is an or, but we really should pass through DataOrCollectionRequestAdapter when we persist the request.

[mvdbeek]

Can you see if you get ext with #21087 ?
We could also apply this on the way out for existing landing requests.

[ahmedhamidawan]

Nice, let me run your branch locally to see what the exact same workflow landing shows

Oh wait 😬 , this landing is from main, so I can't really run it against the same one.

I'll create the same workflow landing locally and then run your branch

[ahmedhamidawan]

Fixed in #21087