What behaviour can change in a Postman collection when a tool sorts or re-nests entries in `item`?
answer
- The risk is in the shape, not the values
- Two structural properties, zero field changes
- Sorting an array is a behavioural edit
- A move rewrites the parent chain
- Check the entry set before the sequence
basics
~10 sTwo things, neither visible as a field diff: order is array position, so sorting rewrites the declared sequence, and nesting decides ancestors, so a move changes which folder auth and event a request inherits.
solid answer
~40 sA collection encodes two behaviours in its structure rather than in any readable value. **Order** is position within an `item` array — there is no `order` key to compare — so sorting or concatenating an array rewrites the declared sequence. **Inheritance reach** follows nesting, because a folder is an entry holding its own `item` list and ancestor-declared `auth` and `event` are found by walking up the parent chain with `findInParents`; move an entry between folders and its ancestor set changes. Both survive a field-level review untouched, which is why a large structural diff on a collection deserves more scrutiny than a small one, not less. Confirm the entry set first, read the resulting sequence rather than the diff hunks, and list the new ancestors of anything that changed level.
code
javascript · 12 linesfunction walk(entries, path) {
entries.forEach((entry, index) => {
const here = path.concat(index + ':' + entry.name);
if (Array.isArray(entry.item)) {
walk(entry.item, here);
} else {
console.log(here.join(' / '));
}
});
}
walk(collection.item, []);go deeper
Be ready to say that moving entries in a collection file is not just tidying: the array position is the order, so a move changes what the file declares.
Explain both structural properties — position carries order, nesting carries ancestor reach — and why neither appears as a changed field in a diff.
Show the review and debugging routine: confirm the entry set, read the new sequence, and for anything that changed level, walk its new ancestors for declarations.
Own the guardrails: which tools may rewrite these files, how structural changes are isolated in review, and whether deep trees are worth the inheritance surface they create.
## Two properties that live in the shape, not in the fields A **Postman collection** encodes two things in the structure of its `item` array rather than in any readable field: - **Order.** The sequence of entries is their position in the array. There is no `order` key, no index property, no recorded sort. - **Inheritance reach.** A folder is an entry holding its own `item` array, so nesting decides which folders are a given request's ancestors — and an ancestor's `auth` or `event` is located by walking up that parent chain with the SDK's `findInParents`. Both are invisible to a review that looks only at values. A tool that sorts, re-nests, regenerates or concatenates entries can change either one while every field in the file stays byte-identical. ## Why a diff hides it A reorder shows up as a block of deletions and a block of insertions. The eye reads that as "moved, no change" and moves on — which is correct about the fields and wrong about the behaviour, because position *is* the order. A re-nest is worse: the entry appears in a different place in the file with the same contents, and nothing in the entry records that it now has different ancestors. ## What a rewrite can do | Rewrite | Effect on order | Effect on inheritance | |---|---|---| | Sorting an `item` array by `name` | declared sequence replaced by alphabetical | none — ancestors unchanged | | Moving an entry into another folder | position changes | ancestor set changes | | Moving an entry to the collection root | position changes | folder declarations no longer in its chain | | Wrapping a group of entries in a new folder | siblings collapse to one position | a new ancestor is inserted for all of them | | Merging two branches by concatenation | sequences interleave or duplicate | usually unchanged, unless a folder was duplicated | | Reformatting whitespace only | none | none | The last row is the one that makes the others dangerous: teams learn that collection files are noisy JSON and start treating every large structural diff as formatting. ## Reviewing a change to a collection file 1. **Confirm the entry set first.** Compare names and counts before reading anything else; a reorder that also drops an entry is easy to miss inside a large move. 2. **Read the resulting sequence**, not the diff hunks. The question is what order the file now declares, which no hunk states directly. 3. **Check nesting separately from order.** For any entry that moved between arrays, list its new ancestors and ask whether any of them declares `auth` or `event`. 4. **Ask what produced the change.** A hand edit in a client, a merge resolution and a regeneration from another source fail in different ways and deserve different scrutiny. ## Habits that keep the file honest - Do not run generic JSON formatters that sort object keys or array elements over a collection file; sorting an array here is a behavioural edit. - Prefer many small, focused collections over one deep tree, so a structural change is legible in review. - Keep structural moves in their own change, separate from edits to requests, so each diff means one thing. - Treat a folder as part of the interface of the requests inside it, because it can carry the `auth` and `event` they inherit. - When a request behaves differently after a merge and its own fields are unchanged, look at where it now sits before looking at what it now says. ## Common mistakes - Calling a reorder cosmetic because no field value changed. - Assuming a client re-sorts entries at load time, so the file's order is advisory. - Believing a re-nest is safe as long as the request body and URL are untouched. - Resolving a merge conflict in an `item` array by keeping both sides and moving on. - Looking for a field that records the intended order so it can be restored — the document keeps none.
- How would you make a structural change to a collection file legible in review?Keep it alone in its own change, so the diff means one thing. Say in the message what moved and where, list any entry that changed level, and avoid mixing request edits into the same commit. Reviewers can then check the entry set, the new sequence and the new ancestors in that order.
- A request signs differently after a merge, yet its own fields are unchanged. Where do you look?At where it now sits. Walk from the entry up to the collection root and note every ancestor declaring `auth`, comparing that chain with the one before the merge. A move between folders changes the candidate declarations without editing the request at all.
saying these in an interview costs you the question
- Calls a reorder cosmetic because no field value changed
- Assumes a client re-sorts entries, so file order is advisory
- Believes a re-nest is safe if the request is untouched
- Resolves an item array conflict by keeping both sides
- Runs a key-sorting JSON formatter over collection files