starred/cypht

Fork 0

mirror of https://github.com/cypht-org/cypht.git synced 2026-04-25 21:15:56 +03:00

[GH-ISSUE #1279] Message content requests are processed synchronously, resulting in a frozen screen when the user clicks on a message row. #617

New issue

Open

opened 2026-02-25 21:35:31 +03:00 by kerem · 7 comments

kerem commented

2026-02-25 21:35:31 +03:00

Owner

Originally created by @mercihabam on GitHub (Oct 10, 2024).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/1279

Originally assigned to: @mercihabam on GitHub.

It would be much better not to have to wait until the request has finished for the app to respond to further actions, such as navigating to another folder or viewing a different message instead of the currently requested one.

I'll explore later how this can be made asynchronous. In the meantime, ideas from everyone are welcome.

Originally created by @mercihabam on GitHub (Oct 10, 2024). Original GitHub issue: https://github.com/cypht-org/cypht/issues/1279 Originally assigned to: @mercihabam on GitHub. It would be much better not to have to wait until the request has finished for the app to respond to further actions, such as navigating to another folder or viewing a different message instead of the currently requested one. I'll explore later how this can be made asynchronous. In the meantime, ideas from everyone are welcome.

kerem commented

2026-02-25 21:35:31 +03:00

Author

Owner

@marclaporte commented on GitHub (Jan 24, 2025):

@kroky please advise

@marclaporte commented on GitHub (Jan 24, 2025): @kroky please advise

kerem commented

2026-02-25 21:35:31 +03:00

Author

Owner

@kroky commented on GitHub (Jan 24, 2025):

We have a deeper problem here as ajax requests are asynchronous by default. I think the actual problem is session locking on the PHP side where your other navigation requests get queued and not responded until the original one is ready but it is not, since it is probably waiting for slow IO from an IMAP server. The best we can do on frontend/UI part is some kind of a spinner/waiting message. Dealing with this on the server-side involves some more complex considerations as when we can close the session early (no further writes), can we have async sessions and things like that. We have discusses similar issues with Tiki codebase, so probably worth doing it on a single place. @marclaporte do you know such a place? I am pretty sure session locking as its own issue or set of issues here and in Tiki.

@kroky commented on GitHub (Jan 24, 2025): We have a deeper problem here as ajax requests are asynchronous by default. I think the actual problem is session locking on the PHP side where your other navigation requests get queued and not responded until the original one is ready but it is not, since it is probably waiting for slow IO from an IMAP server. The best we can do on frontend/UI part is some kind of a spinner/waiting message. Dealing with this on the server-side involves some more complex considerations as when we can close the session early (no further writes), can we have async sessions and things like that. We have discusses similar issues with Tiki codebase, so probably worth doing it on a single place. @marclaporte do you know such a place? I am pretty sure session locking as its own issue or set of issues here and in Tiki.

kerem commented

2026-02-25 21:35:31 +03:00

Author

Owner

@marclaporte commented on GitHub (Feb 1, 2025):

do you know such a place?

@kroky Do you mean where we should discuss or which parts of the code?

@marclaporte commented on GitHub (Feb 1, 2025): > do you know such a place? @kroky Do you mean where we should discuss or which parts of the code?

kerem commented

2026-02-25 21:35:31 +03:00

Author

Owner

@kroky commented on GitHub (Feb 3, 2025):

I think we had a session locking discussion for Tiki somewhere with you but I cannot find the thread - was wondering if you remember it?

@kroky commented on GitHub (Feb 3, 2025): I think we had a session locking discussion for Tiki somewhere with you but I cannot find the thread - was wondering if you remember it?

kerem commented

2026-02-25 21:35:31 +03:00

Author

Owner

@marclaporte commented on GitHub (Feb 3, 2025):

https://dev.tiki.org/item8365-Race-condition-Sessions-stored-in-the-database-and-Cypht

Internal tasks:

@marclaporte commented on GitHub (Feb 3, 2025): https://dev.tiki.org/item8365-Race-condition-Sessions-stored-in-the-database-and-Cypht Internal tasks: - https://avan.tech/item89272-Revamp-our-db-session-storage-to-work-in-exclusive-locking-mode-like-native-file-session-storage-works - https://avan.tech/item88244-With-session_storage-db-in-24x-Cypht-reply-to-empty-instead-of-sender

kerem commented

2026-02-25 21:35:31 +03:00

Author

Owner

@kroky commented on GitHub (Feb 4, 2025):

Thanks! I've checked the discussions we had and they involve both Tiki and Tiki-Cypht integration. Part of the updates/fixes for locking and truly asynchronous requests were in Tiki-Cypht integration but now we need to think about standalone Cypht. Recent changes in master made the db-stored sessions work in exclusive lock mode like the file storage sessions in PHP. This is a step forward towards unification. Since Cypht is a heavy user of ajax requests, I think next steps would involve:

analyze and list potentially slow ajax endpoints (anything involving IO with 3rd party server)
analyze session usage for each Cypht module and potentially reduce the usage of session only to where it is absolutely necessary
refactor to close the session early when further modules don't write data in the session (this is already happening in a couple of places but needs more coverage)
consider switching to read-write-close session handling for asynchronous requests - we need to make sure session is freshly read every time it is used and then written and closed when something needs to be stored. This way, parallel requests can access and share the same data. Special care must be taken in not using an old/stale data in a session cache.
session locking must still be implemented during write operations, so concurrent write issues are solved
consider data integrity checks stored as hashes, so subsequent reads of async requests know if their data is fresh or not and if they should reload it (should speed up the session management operations)

@kroky commented on GitHub (Feb 4, 2025): Thanks! I've checked the discussions we had and they involve both Tiki and Tiki-Cypht integration. Part of the updates/fixes for locking and truly asynchronous requests were in Tiki-Cypht integration but now we need to think about standalone Cypht. Recent changes in master made the db-stored sessions work in exclusive lock mode like the file storage sessions in PHP. This is a step forward towards unification. Since Cypht is a heavy user of ajax requests, I think next steps would involve: - analyze and list potentially slow ajax endpoints (anything involving IO with 3rd party server) - analyze session usage for each Cypht module and potentially reduce the usage of session only to where it is absolutely necessary - refactor to close the session early when further modules don't write data in the session (this is already happening in a couple of places but needs more coverage) - consider switching to read-write-close session handling for asynchronous requests - we need to make sure session is freshly read every time it is used and then written and closed when something needs to be stored. This way, parallel requests can access and share the same data. Special care must be taken in not using an old/stale data in a session cache. - session locking must still be implemented during write operations, so concurrent write issues are solved - consider data integrity checks stored as hashes, so subsequent reads of async requests know if their data is fresh or not and if they should reload it (should speed up the session management operations)

kerem commented

2026-02-25 21:35:31 +03:00

Author

Owner

@marclaporte commented on GitHub (Feb 5, 2025):

@jasonmunro wrote in the community chatroom:

"Yep, that is a tricky one :) Kroky is correct I believe, the "problem" is session locking. The best I could come up with to help mitigate that was to allow requests to close the session early so any non-writing action can be performed after the session is closed: github.com/cypht-org/cypht@13e3a960a4/modules/core/handler_modules.php (L120)"

Source: https://matrix.to/#/!SeNiIGzqZwRjAclUCr:gitter.im/$7B90VpPjtYJJPygxtN51hDIEeaeSmqmkENfje65FiSo?via=matrix.org&via=gitter.im&via=osba.nl

@marclaporte commented on GitHub (Feb 5, 2025): @jasonmunro wrote in the community chatroom: "Yep, that is a tricky one :) Kroky is correct I believe, the "problem" is session locking. The best I could come up with to help mitigate that was to allow requests to close the session early so any non-writing action can be performed after the session is closed: https://github.com/cypht-org/cypht/blob/13e3a960a4ba225253962d9d31c1f5bada39e838/modules/core/handler_modules.php#L120" Source: https://matrix.to/#/!SeNiIGzqZwRjAclUCr:gitter.im/$7B90VpPjtYJJPygxtN51hDIEeaeSmqmkENfje65FiSo?via=matrix.org&via=gitter.im&via=osba.nl