feat: cache file uploads so the upload button is not re-resolved every run - #84
Open
Agam00 wants to merge 1 commit into
Open
feat: cache file uploads so the upload button is not re-resolved every run#84Agam00 wants to merge 1 commit into
Agam00 wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
browser_upload_fileis the only tool that doesn't write a cache entry.click,fill,hoverandselectOptionall callprepareCacheData, uploads never did.So every run asks the model to find the upload button again. Usually it finds it. When it doesn't, the step uses up its full 3 minute timeout and fails a test that had nothing to do with uploading. That happened to us three times in one week, in three different suites.
What
This caches the button that opens the file chooser, and replays both steps against it on later runs.
The upload itself is unchanged. Still
waitForEvent('filechooser')then click thensetFiles. The only thing that goes away is asking the model where the button is.Nothing to configure. Existing
browser_upload_filesteps get this automatically.I did look at using
locator.setInputFiles()to make it a single action, but that only works when the button is a label wrapped around the input, and the file chooser flow is closer to what a real user does. So I left that part alone.Worth a look
const input = step.data?.value || valueisn't safe for uploads.step.data.valueis just a filename, while the cachedvaluealready has the folder on the front. Sincestep.datawins, usinginputdirectly would add the folder twice and give you./uploads/./uploads/file.pdf. That only breaks on the second run, so I moved the logic intoresolveCachedUploadPathsand added a test for exactly that case.Also worth knowing if you try this out: caching only happens for steps that resolve to a single tool call. A step written as several actions, like "click the drop area, find the input, attach the file", never gets cached no matter what this PR does.
Testing
Build is clean, 171 tests pass (5 new), and lint has no new errors.
I also ran it against a real suite. First run resolved the button through the model and saved it, second run replayed it with no model call:
Executing Cached Step: Upload value using the "browse documents" control...
const fileChooserPromise = page.waitForEvent('filechooser');
await page.getByRole('button', { name: 'Drag and drop or browse' }).click({ timeout: 5000 });
const fileChooser = await fileChooserPromise;
await fileChooser.setFiles(["./uploads/David_Thompson_Client_Case_File.pdf"]);
I didn't run
format:check. The globs in that script don't expand on Windows, and the checked in tree isn't prettier clean anyway (42 files come up, including ones I didn't touch). I checked my own lines against the config separately and they're fine.