Describe the bug
Importing an Insomnia v5 (YAML) collection fails with:
Import collection failed: An error occurred while parsing the Insomnia v5 collection: t.match is not a function
The crash occurs when a request parameter / path-parameter / header value is an unquoted scalar that the YAML loader resolves to a number instead of a string.
Root cause
In Insomnia v5 YAML, values are often emitted unquoted, e.g.:
parameters:
- name: item-id
value: 1.0_172666493691943363636Under YAML 1.1 semantics, underscores are digit separators inside numbers, so 1.0_172666493691943363636 matches the float pattern and is resolved to a number (1.0172666493691944), not a string.
Bruno's v5 importer then calls .match() on the value (assuming it is a string). Numbers have no .match() method, so import aborts with t.match is not a function. The same happens for any numeric-looking value: large integer IDs, timestamps, version strings, etc.
Steps to reproduce
- Save the minimal collection below as
repro.yaml.
- In Bruno: Import -> Insomnia Collection v5 -> select
repro.yaml.
- Import fails with
t.match is not a function.
repro.yaml
type: collection.insomnia.rest/5.0
schema_version: "5.1"
name: Bruno Import Repro
meta:
id: wrk_repro
created: 1700000000000
modified: 1700000000000
description: ""
collection:
- url: https://example.com/api/items
name: Get item
meta:
id: req_repro_0001
created: 1700000000000
modified: 1700000000000
isPrivate: false
description: ""
sortKey: -1700000000000
method: GET
parameters:
- name: item-id
value: 1.0_172666493691943363636
description: ""
settings:
renderRequestBody: true
encodeUrl: true
followRedirects: global
cookies:
send: true
store: true
rebuildPath: true
Expected behavior
Import should succeed. Parameter / path / header values should be coerced to strings (e.g. String(value)) before any .match() / string operation, so non-string YAML scalars import cleanly.
Workaround
Quote the offending value in the YAML before importing:
value: "1.0_172666493691943363636"
Notes
- This is not exotic - Insomnia itself exports such IDs unquoted, so real collections with numeric-looking IDs hit it routinely.
- A collection that has no number-like unquoted values imports fine, which is why some exports work and others do not.
Describe the bug
Importing an Insomnia v5 (YAML) collection fails with:
The crash occurs when a request parameter / path-parameter / header value is an unquoted scalar that the YAML loader resolves to a number instead of a string.
Root cause
In Insomnia v5 YAML, values are often emitted unquoted, e.g.:
Under YAML 1.1 semantics, underscores are digit separators inside numbers, so
1.0_172666493691943363636matches the float pattern and is resolved to a number (1.0172666493691944), not a string.Bruno's v5 importer then calls
.match()on the value (assuming it is a string). Numbers have no.match()method, so import aborts witht.match is not a function. The same happens for any numeric-looking value: large integer IDs, timestamps, version strings, etc.Steps to reproduce
repro.yaml.repro.yaml.t.match is not a function.repro.yaml
Expected behavior
Import should succeed. Parameter / path / header values should be coerced to strings (e.g.
String(value)) before any.match()/ string operation, so non-string YAML scalars import cleanly.Workaround
Quote the offending value in the YAML before importing:
Notes