Fix actions fetching logic and loading state, prevent duplicate toasts

[silverwind]

1. Fix the bug where action steps would not expand sometimes. This was because when a fetch was running and the user clicked "expand" it would not propagate the expansion request to the backend, leaving the UI state invalid. Fixed this by adding a force flag.
2. When a fetch failed, it would just throw the error and the browser would dump it into the console, invisible to the user. Show a toast in such a case.
3. Add a dedicated loading state to steps to ensure they can not get stuck in that state when cursor remains at null, for example when a fetch error happened.

Also, because in the actions view, fetches can fail repeatedly because of the refreshing, I saw the need to introduce a deduplication for toasts, so if an attempt is made to raise a toast with the same message and level, it will suppress opening them.

[lunny]

Could we split these as two PRs for easier review?

[silverwind]

Can't easily split this because if I remove only the toast changes, there would be the problem of repeated error toasts every second because of that refresh mechanism. The only thing that could be done is to have a reduced backport that only fixes issue 1 with the force flag.

[silverwind]

BTW one reason we need the toast deduplication: Go to admin dashboard and disconnect your network:

[wxiaoguang]

Missed this review request.

No block from my side (I don't use Actions and I haven't spent time on reading code), just share some opinions:

1. the loadData state management becomes more and more complex and fragile, at first glance I can't tell whether it is complete but I guess there could be some edge cases, for example: force=true will reset other this.loading=true
2. maybe there should be some tests to cover some functions (even without e2e test, we could mock and test some code blocks)
3. the change of showToast is quite hacky
   • preventDuplicates should not default to true, it is a breaking behavior.
   • it should hide the existing toast, but not skip the new toast.
4. it shouldn't be backported since the change is not covered by tests, and it doesn't fix blocker problems for end users.

[silverwind]

maybe there should be some tests to cover some functions (even without e2e test, we could mock and test some code blocks)

Quite hard I assume unless Vue works in happy-dom, but I would doubt that. Maybe with some Vue-specific testing framework, but I have no experience with those.

preventDuplicates should not default to true, it is a breaking behavior.

It helps with other cases like systems stats flooding the page with error toasts when going offline.

it should hide the existing toast, but not skip the new toast.

This is actually a nice idea, I will try to implement.

it shouldn't be backported since the change is not covered by tests, and it doesn't fix blocker problems for end users.

It's quite annoying when you click an action step and nothing happens though. Happens to me like a third of the time.

[silverwind]

Will also fix the boolean trap with loadData :)

[wxiaoguang]

maybe there should be some tests to cover some functions (even without e2e test, we could mock and test some code blocks)

Quite hard I assume unless Vue works in happy-dom, but I would doubt that. Maybe with some Vue-specific testing framework, but I have no experience with those.

Maybe something like "Improve <SvgIcon> to make it output svg node and optimize performance (#23570)"

[silverwind]

Right, this createApp + mount pattern I had a helper function in another PR, so likely tests could use it in place of this h function.

BTW, I think I will extract the toast changes to another PR. I have a few improvements in mind.

[silverwind]

Ah, I see you went with the "default enabled" variant, so yes in this case we don't need to special-case these callers. I will remove all toast-related code from this commit.

[wxiaoguang]

OK, I am sure the state management is not right now. See the duplicate lines:

That's my first worry in #31124 (review)

[wxiaoguang]

@silverwind you edited my comment ...... (reverted)

To answer:

Got some steps how to reproduce that?

I think the reason is still related to the "force" behavior: to produce, make the backend sleep 500-1500ms to respond to make the edge cases could easily be triggered, then toggle the steps multiple times, then since you use force to reset the loading, then there are multiple requests in flight, then they get duplicate results.

[silverwind]

Sorry, meant to reply. I will rework this later.

[silverwind]

FYI https://codeberg.org/forgejo/forgejo/pulls/6122 is related and deals with the same bug of the job step sometimes not expanding.

[wxiaoguang]

FYI https://codeberg.org/forgejo/forgejo/pulls/6122 is related and deals with the same bug of the job step sometimes not expanding.

Just take a quick look, I do not think it is right, it seems to be a hacky patch.

[wxiaoguang]

I will try to work on it in the following few days, to see whether we could properly fix it in 1.23

[silverwind]

I will try to work on it in the following few days, to see whether we could properly fix it in 1.23

Thanks, I haven't gotten around to this. I hope you can reproduce the issue. It happens when a job is expanded while the fetch is still running.

[wxiaoguang]

Done, see this: Refactor RepoActionView.vue #32713

[mfenniak]

In the event that a force request is received, I think that there will be a race condition that may cause a similar problem to the one that you're attempting to solve, occasionally:

There's loadData(A) which was already running, and then loadData(B) which was running with the force flag. If loadData(B) returns from the server first, and then loadData(A)'s data returns from the server afterwards, I believe the log data will be reverted back to the data from the first request.

[wxiaoguang]

Yup, that's why I blocked this PR from merging #31124 (comment)

replaced by #32713

[lunny]

Replaced by #32713 ?

[silverwind]

Yes, that includes the most important fix. As for the other 2 topics, I think we can do them another time.