starred/koel-koel

Fork 0

mirror of https://github.com/koel/koel.git synced 2026-04-26 17:25:59 +03:00

[GH-ISSUE #1934] [Bug]: Filter persists invisibly after switching playlists #1039

New issue

Closed

opened 2026-02-26 02:35:02 +03:00 by kerem · 6 comments

kerem commented

2026-02-26 02:35:02 +03:00

Owner

Originally created by @HNIdesu on GitHub (May 29, 2025).
Original GitHub issue: https://github.com/koel/koel/issues/1934

Originally assigned to: @phanan on GitHub.

Read the Troubleshooting guide.

I have read and followed the Troubleshooting guide

Reproduction steps

Open a playlist (e.g. Playlist A).
Enter a filter keyword into the filter input.
Switch to another playlist (e.g. Playlist B).

Expected behavior

Switching to another playlist should reset the filter state, both visually (empty input) and functionally (full song list shown).

Actual behavior

The filter input appears empty.
The displayed songs in Playlist B are still filtered as if the same keyword is applied.

Logs

No response

Koel version

Koel v7.5.1 Community Edition

How did you install Koel?

Compiled from source

Additional information

Originally created by @HNIdesu on GitHub (May 29, 2025). Original GitHub issue: https://github.com/koel/koel/issues/1934 Originally assigned to: @phanan on GitHub. ### Read the Troubleshooting guide. - [x] I have read and followed the Troubleshooting guide ### Reproduction steps 1. Open a playlist (e.g. Playlist A). 2. Enter a filter keyword into the filter input. 3. Switch to another playlist (e.g. Playlist B). ### Expected behavior Switching to another playlist should reset the filter state, both visually (empty input) and functionally (full song list shown). ### Actual behavior The filter input appears empty. The displayed songs in Playlist B are still filtered as if the same keyword is applied. ### Logs _No response_ ### Koel version Koel v7.5.1 Community Edition ### How did you install Koel? Compiled from source ### Additional information

kerem closed this issue

2026-02-26 02:35:02 +03:00

kerem commented

2026-02-26 02:35:03 +03:00

Author

Owner

@phanan commented on GitHub (May 29, 2025):

Confirmed. I think it’s due time to handle separated playlist states once
and for all.

On Thu, May 29, 2025 at 06:07 HNIdesu @.***> wrote:

Assigned #1934 https://github.com/koel/koel/issues/1934 to @phanan
https://github.com/phanan.

—
Reply to this email directly, view it on GitHub
https://github.com/koel/koel/issues/1934#event-17861365448, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AB5O3UWGIF64ZWD7CFPLNFL3A2BWXAVCNFSM6AAAAAB6EPAC66VHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJXHA3DCMZWGU2DIOA
.
You are receiving this because you were assigned.Message ID:
@.***>

@phanan commented on GitHub (May 29, 2025): Confirmed. I think it’s due time to handle separated playlist states once and for all. On Thu, May 29, 2025 at 06:07 HNIdesu ***@***.***> wrote: > Assigned #1934 <https://github.com/koel/koel/issues/1934> to @phanan > <https://github.com/phanan>. > > — > Reply to this email directly, view it on GitHub > <https://github.com/koel/koel/issues/1934#event-17861365448>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AB5O3UWGIF64ZWD7CFPLNFL3A2BWXAVCNFSM6AAAAAB6EPAC66VHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJXHA3DCMZWGU2DIOA> > . > You are receiving this because you were assigned.Message ID: > ***@***.***> >

kerem commented

2026-02-26 02:35:03 +03:00

Author

Owner

@HNIdesu commented on GitHub (Jun 1, 2025):

Thanks for the fix! However, I noticed a couple of side effects after the change:

1. Filtered results change when returning to a playlist

Steps:

In Playlist A, enter a filter keyword (e.g. abc)
Switch to Playlist B
Switch back to Playlist A
➡️ The filtered results in A have changed, even though the filter string remains

2. Same filter string causes result "leakage" across playlists

Steps:

In Playlist A, enter abc
Switch to Playlist B and enter the same abc
Switch back to Playlist A
➡️ You now see Playlist B's filtered results in Playlist A

It seems that while the search keyword is stored per playlist, the actual filtered result might be shared or recalculated improperly based on the current global context. Maybe each (playlistId + filter) pair needs to have its own result reference or cache?

Let me know if you'd like more detail or reproduction steps!

@HNIdesu commented on GitHub (Jun 1, 2025): Thanks for the fix! However, I noticed a couple of side effects after the change: --- ### 1. Filtered results change when returning to a playlist Steps: 1. In Playlist A, enter a filter keyword (e.g. `abc`) 2. Switch to Playlist B 3. Switch back to Playlist A ➡️ The filtered results in A have changed, even though the filter string remains --- ### 2. Same filter string causes result "leakage" across playlists Steps: 1. In Playlist A, enter `abc` 2. Switch to Playlist B and enter the same `abc` 3. Switch back to Playlist A ➡️ You now see Playlist B's filtered results in Playlist A --- It seems that while the search keyword is stored per playlist, the actual filtered result might be shared or recalculated improperly based on the current global context. Maybe each `(playlistId + filter)` pair needs to have its own result reference or cache? Let me know if you'd like more detail or reproduction steps!

kerem commented

2026-02-26 02:35:03 +03:00

Author

Owner

@phanan commented on GitHub (Jun 1, 2025):

Hmm, as every engineer out there I could have sworn I tested the changes
thoroughly and it worked on my machine 😅 Will take another look.

On Sun, Jun 1, 2025 at 04:57 HNIdesu @.***> wrote:

HNIdesu left a comment (koel/koel#1934)
https://github.com/koel/koel/issues/1934#issuecomment-2926337572

Thanks for the fix! However, I noticed a couple of side effects after the
change:

Filtered results change when returning to a playlist

Steps:

In Playlist A, enter a filter keyword (e.g. abc)

Switch to Playlist B

Switch back to Playlist A
➡️ The filtered results in A have changed, even though the filter
string remains

Same filter string causes result "leakage" across playlists

Steps:

In Playlist A, enter abc

Switch to Playlist B and enter the same abc

Switch back to Playlist A
➡️ You now see Playlist B's filtered results in Playlist A

It seems that while the search keyword is stored per playlist, the actual
filtered result might be shared or recalculated improperly based on the
current global context. Maybe each (playlistId + filter) pair needs to
have its own result reference or cache?

Let me know if you'd like more detail or reproduction steps!

—
Reply to this email directly, view it on GitHub
https://github.com/koel/koel/issues/1934#issuecomment-2926337572, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AB5O3UVUHUP6JCLF36DNDNT3BJTZFAVCNFSM6AAAAAB6EPAC66VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMRWGMZTONJXGI
.
You are receiving this because you modified the open/close state.Message
ID: @.***>

@phanan commented on GitHub (Jun 1, 2025): Hmm, as every engineer out there I could have sworn I tested the changes thoroughly and it worked on my machine 😅 Will take another look. On Sun, Jun 1, 2025 at 04:57 HNIdesu ***@***.***> wrote: > *HNIdesu* left a comment (koel/koel#1934) > <https://github.com/koel/koel/issues/1934#issuecomment-2926337572> > > Thanks for the fix! However, I noticed a couple of side effects after the > change: > ------------------------------ > 1. Filtered results change when returning to a playlist > > Steps: > > 1. In Playlist A, enter a filter keyword (e.g. abc) > 2. Switch to Playlist B > 3. Switch back to Playlist A > ➡️ The filtered results in A have changed, even though the filter > string remains > > ------------------------------ > 2. Same filter string causes result "leakage" across playlists > > Steps: > > 1. In Playlist A, enter abc > 2. Switch to Playlist B and enter the same abc > 3. Switch back to Playlist A > ➡️ You now see Playlist B's filtered results in Playlist A > > ------------------------------ > > It seems that while the search keyword is stored per playlist, the actual > filtered result might be shared or recalculated improperly based on the > current global context. Maybe each (playlistId + filter) pair needs to > have its own result reference or cache? > > Let me know if you'd like more detail or reproduction steps! > > — > Reply to this email directly, view it on GitHub > <https://github.com/koel/koel/issues/1934#issuecomment-2926337572>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AB5O3UVUHUP6JCLF36DNDNT3BJTZFAVCNFSM6AAAAAB6EPAC66VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMRWGMZTONJXGI> > . > You are receiving this because you modified the open/close state.Message > ID: ***@***.***> >

kerem commented

2026-02-26 02:35:03 +03:00

Author

Owner

@phanan commented on GitHub (Jun 1, 2025):

Actually, no, I don't think I can reproduce. Please make sure the scripts are compiled and not cached.

@phanan commented on GitHub (Jun 1, 2025): Actually, no, I don't think I can reproduce. Please make sure the scripts are compiled and not cached.

kerem commented

2026-02-26 02:35:03 +03:00

Author

Owner

@phanan commented on GitHub (Jun 1, 2025):

Ah ok I think I'm on to something.

@phanan commented on GitHub (Jun 1, 2025): Ah ok I think I'm on to something.

kerem commented

2026-02-26 02:35:03 +03:00

Author

Owner

@phanan commented on GitHub (Jun 1, 2025):

Fixed and released in v7.5.2

@phanan commented on GitHub (Jun 1, 2025): Fixed and released in v7.5.2

kerem referenced this issue

2026-02-26 03:31:24 +03:00

[PR #1039] [MERGED] Apply fixes from StyleCI #1541

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/koel-koel#1039

No description provided.

Rows
Columns