I have a data-driven collection run; which uses the file “API Data Driven Demo File.json”; that I can execute successfully when I execute the run manually.
When I try to create a new monitor to run the same collection automatically on a schedule, Postman won’t let me create the monitor. I discovered have to delete the spaces in the name of the “API Data Driven Demo File.json” file … to get “API Data Driven Demo File.json” … and THEN Postman will let me create the monitor.
This is all to do with the way that the data file is stored on for those Monitors run, it’s not reading them from your local file systems like with the Collection Runner.
Perhaps if file attachments for data-driven collections are going to be denied if they contain spaces and/or special characters in their file names when creating a monitor to run a collection automatically, that same restriction should be applied when attaching a file to run the data-driven collection manually.
Moving the error message down to the file attachment field might be good to do too.
Anyway, the work around is not to have any spaces and/or special characters in the file name.
I just wasn’t sure if the differences in functionality related to attaching files that I experienced was intended, or someone forgot to add the validation/check on the manual collection run page.
Being a new Postman user I found it weird for different pages of the UI to have different functionality related to the validation of a file attachment.
When attempting creation/editing of a monitor to run a data-driven collection automatically; and part of the validation process for the attachment is to prevent creation of a monitor when the attachment filename contains spaces and/or special characters; maybe that same restriction should be applied when attaching a file to run the data-driven collection manually, for consistency in the UI.
Moving the error message down to the “Data file (optional)” field might be a good thing to do too, because it has nothing to do with the input in the “Monitor name” field.
I’m a QA, so I KNOW I’m being picky.
Bottom line is I figured out what the issue was, and I’ve got my workaround.
I was just curious if the difference in UI functionality was a bug or as intended.
I’m still not sure if you saw the error message in the UI or not. You didn’t mention that
I agree about the location of the message and I even mentioned that it’s not 100% clear what the message refers to or that you can’t have spaces in the name. I’ll flag this up to the team. Ideally, that should come when you try and attach the file not when you hit the Create button.
We also don’t mention that on the Learning Center so that’s another area that can be updated to reflect the usage.
The way that data files are handled between those 2 features is different, the Collection Runner is reading the file straight from file system and it’s not storing that anywhere.
The Monitors are not run on your local machine with or without a file. When a data file is used we’re storing the variables and use the original filename. The filename should contain characters that are valid for an S3 object. The error message reflects what are not valid characters.
Sorry. Yes. I saw the error message … eventually … once I scrolled up to the top of the page after seeing the “Monitor could not be loaded” error message at the bottom of the page a couple of times.
I was surprised by the failure to create the monitor because I was using the exact same file I used for the manual run of the collection; which ran successfully. Since I wasn’t seeing any error message at the "Data file (optional) field I initially didn’t think there was a problem with the file attachment for the monitor I was trying to create.
When I first read the error message under the “Monitor name” field (which I obviously read too quickly) I automatically assumed the message had something to do with the name field because of where the message was appearing. I re-read the error message a couple of times; finally clued in (duh) that the error message was tied to the file I was attaching; but was still thrown off because there was no issue with the same file name during the manual run of the collection.
Bottom line … I finally clued in, and figured out what was going on.
