This message was deleted.
# proj-release
d
This message was deleted.
thonk 1
b
Agent has started with
npm start
which always used to auto refresh.
w
would be curious what's inside the
start
script in
package.json
f
Is the refresh issue consistent? It's hard to tell but Robert may be right, some very basic setups don't include hot module reloading (HMR) which auto restart the FE server on changes For the Changes tab, that is a present issue I want to get fixed. It was done to solve another issue that came with the downside of always loading until agent finished
b
Yes consistent. It may be a new way OpenHands runs the app if ya'll changed something but before it always auto refreshed. Now even changing tabs doesn't work and needs a browser refresh
w
came with the downside of always loading until agent finished
We definitely need to fix this ASAP--we shouldn't have checked in that regression
let's prioritize that
f
We definitely need to fix this ASAP--we shouldn't have checked in that regression
Sorry, I should have made the consequence clearer 😓 There is an alternative I can push ASAP, but not 100% reliable
w
All good 🙂 but yeah we should be very clear when there's a regression being checked in Just so I'm clear--this is the issue where the changes tab is not showing changes until the agent is finished with its work, right?
nod 1
Rather than refreshing on every file change?
f
Something like that. The issue is we use to use
invalidateQuery
that would trigger a refetch on file changes. That caused a serious issue where loading existing conversations would call that method on every file change, and trigger a new request as well, causing a huge burst of these calls and possibly self-DOSing The change was to use
removeQuery
instead, that clears all cache and does not request a refetch.
aha 1
That's why we always see it loading, it fetches instead of refetches w/ cache
w
Got it. Does react query not have any debouncing when you invalidate?
f
No, but there is a
cancelRefetch
option where I'd pass the boolean value that determines whether we're receiving messages at a high rate (the same value that determines whether we display the messages or wait for them to finish loading)
Shouldn't be an issue for most cases and I don't think I've encountered an issue so far with it, but still feels suboptimal
w
better than not fetching 🙂
nod 1
f
thanks on a stick 1
🍰 1