[olsonanl]

The bug

The download wizard's FASTA preview promised |-separated description fields. The download delivered spaces.

preview:   >patric_id| strain | host_name | isolation_country
download:  >fig|1545742.911.peg.9| MGYG-HGUT-00869 Human USA

Two independent hardcodings that disagreed:

// FASTAConfiguratorStep.js:358 — preview
previewParts.push(descFields.join(' | '));

// p3_api util/fastaHeaderFormatter.js — server
const description = formatFields(doc, config.descriptionFields, ' ')

The server's delimiter was a literal argument, not a parameter, so no request could change it. It now accepts http_fasta_description_delimiter — this PR sends it.

after:  >fig|1545742.911.peg.9| MGYG-HGUT-00869 | Human | USA

Verified against alpha; the rendered header now matches the preview exactly.

What changed

• Send http_fasta_id_delimiter and http_fasta_description_delimiter. The ID delimiter goes at the server's own default (|), so nothing changes for a user who doesn't touch it. The description delimiter is ' | ' — what the preview has always shown, and what makes a multi-field description parseable, since several values (host_name, product) contain spaces of their own.
• Derive the preview from the same values rather than a second hardcoded string. Also escapes it, since field names and delimiters land in innerHTML.
• Collapse duplicated parameter-building. Three places built these params — the form-POST path, the xhr path, and the in-browser convertToFasta, each with its own copy of the delimiters. The first two are now one buildFastaParams(); the third reads the configured values instead of hardcoding '|' and ' '. That duplication is how the preview drifted from the download in the first place, and the third copy would have kept producing the old output on the client-side route.

Absent vs empty

An absent delimiter is omitted — leave the server's default alone. An empty one is transmitted, because "" is a meaningful delimiter meaning "run the fields together". Hence !== undefined rather than a falsiness check, which would silently drop that choice.

Testing

8 new tests covering both request paths, with one asserting they agree. Suite at 171 passing; lint unchanged from baseline.

Mutation-tested rather than assumed: removing the delimiter-sending makes exactly 4 of the 8 fail. The other 4 guard adjacent behaviour (field params, absent-delimiter omission, no-config) and correctly stay green.

Manual check — a FASTA download from a genome_feature grid with several description fields selected should now produce a header matching the preview character for character.

Scope

First of five steps in PLAN-fasta-header-formats.md, included here. The rest — delimiter controls in the UI, format-string mode (http_fasta_header), saved named formats in the workspace, and replacing the hardcoded field list with /fields — build on this but are not in this PR.

REPORT-fasta-header-presets.md is also included: seven NCBI and GISAID/augur format strings verified against live alpha, with real output and the data traps behind them (subtype carries Influenza B for type-B records; strain is empty on ~2% of influenza genomes and leads the GISAID format; {patric_id} contains a pipe).

🤖 Generated with Claude Code