updateCollectionRequest replaces the request's entire events array with whatever is passed in, rather than merging by event type. This causes silent data loss: when a request has both a pre-request and a post-response (test) script, updating only one of them deletes the other.
There is no error. The script just disappears from the request.
Root cause
In src/tools/updateCollectionRequest.ts (v2.8.9, line 434):
if (args.events !== undefined) bodyPayload.events = args.events;
The incoming events array is sent as-is, fully overwriting the existing events. The Postman endpoint behaves like PATCH for top-level fields, but events itself is treated as a full replacement.
Steps to reproduce
- Have a request with both scripts:
"events": [
{ "listen": "prerequest", "script": { "type": "text/javascript", "exec": ["// generate auth token"] } },
{ "listen": "test", "script": { "type": "text/javascript", "exec": ["pm.test('old', () => {})"] } }
]
- Call updateCollectionRequest to update only the post-response script:
{
"requestId": "...",
"collectionId": "...",
"events": [
{ "listen": "test", "script": { "type": "text/javascript", "exec": ["pm.test('new', () => {})"] } }
]
}
- Inspect the request.
Expected
The prerequest script is preserved; only the test script is updated.
Actual
The prerequest script is gone. The request now has only the test event.
Impact
This is easy to hit with AI agents driving the tool: the natural instruction "update the post-response script of this request" produces exactly the payload above, silently wiping any existing pre-request
script. It's especially dangerous in bulk operations across many requests, where the loss may go unnoticed.
Possible fixes (in order of preference)
- Event-aware merge: before writing, fetch the request's current events, and merge by listen type so untouched event types are preserved. Replace only the event type(s) present in the input.
- Documentation warning: at minimum, the tool's description should clearly state that events is replaced wholesale, and that callers must include all existing event types they wish to keep.
- Dedicated helper tool (e.g. updateRequestScript) that takes a single listen + exec and performs the merge internally.
Happy to open a PR if the maintainers have a preferred direction. (Noting the tools appear to be synced from an internal source per #145, so I wanted to raise this as an issue first rather than send an unsolicited PR.)
updateCollectionRequest replaces the request's entire events array with whatever is passed in, rather than merging by event type. This causes silent data loss: when a request has both a pre-request and a post-response (test) script, updating only one of them deletes the other.
There is no error. The script just disappears from the request.
Root cause
In src/tools/updateCollectionRequest.ts (v2.8.9, line 434):
if (args.events !== undefined) bodyPayload.events = args.events;
The incoming events array is sent as-is, fully overwriting the existing events. The Postman endpoint behaves like PATCH for top-level fields, but events itself is treated as a full replacement.
Steps to reproduce
"events": [
{ "listen": "prerequest", "script": { "type": "text/javascript", "exec": ["// generate auth token"] } },
{ "listen": "test", "script": { "type": "text/javascript", "exec": ["pm.test('old', () => {})"] } }
]
{
"requestId": "...",
"collectionId": "...",
"events": [
{ "listen": "test", "script": { "type": "text/javascript", "exec": ["pm.test('new', () => {})"] } }
]
}
Expected
The prerequest script is preserved; only the test script is updated.
Actual
The prerequest script is gone. The request now has only the test event.
Impact
This is easy to hit with AI agents driving the tool: the natural instruction "update the post-response script of this request" produces exactly the payload above, silently wiping any existing pre-request
script. It's especially dangerous in bulk operations across many requests, where the loss may go unnoticed.
Possible fixes (in order of preference)
Happy to open a PR if the maintainers have a preferred direction. (Noting the tools appear to be synced from an internal source per #145, so I wanted to raise this as an issue first rather than send an unsolicited PR.)