Skip to content

[WIP] [persistence] Store the time of the update not the time the store occurred #21160

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mjagdis wants to merge 10 commits into
base: main
Choose a base branch
from
Open

[WIP] [persistence] Store the time of the update not the time the store occurred #21160

Changes from 1 commit
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
491da36
[dynamodb] Store the time of the update not the time the store occurred
mjagdis Jul 11, 2026
5881b35
[dynamodb] Filter criteria are <= and >= not < and >
mjagdis Jul 11, 2026
f3990e4
[dynamodb] Fix tests
mjagdis Jul 11, 2026
94d977d
[inmemory] Store the time of the update not the time the store occurred
mjagdis Jul 11, 2026
15ec1c7
[jdbc] Store the time of the update not the time the store occurred
mjagdis Jul 11, 2026
4737949
[jpa] Store the time of the update not the time the store occurred
mjagdis Jul 11, 2026
e669fa1
[mongodb] Store the time of the update not the time the store occurred
mjagdis Jul 11, 2026
3a4ad70
[rrd4j] Store the time of the update not the time the store occurred
mjagdis Jul 11, 2026
8a2819b
[timescaledb] Store the time of the update not the time the store occ…
mjagdis Jul 12, 2026
5ef2eee
[dynamodb] Fix handling of sortBetween
mjagdis Jul 12, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion ...b/src/main/java/org/openhab/persistence/dynamodb/internal/DynamoDBPersistenceService.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -496,7 +496,8 @@ public void store(Item item) {
@Override
public void store(Item item, @Nullable String alias) {
// Timestamp and capture state immediately as rest of the store is asynchronous (state might change in between)
ZonedDateTime time = ZonedDateTime.now();
ZonedDateTime lastStateUpdate = item.getLastStateUpdate();

@ssalonen ssalonen Jul 12, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it guaranteed by the core that this timestamp is updated when persistence is called?

@mjagdis mjagdis Jul 12, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. If it isn't mapdb would have been badly broken for a long time and that would be Bad. It would also be a bug in the core since state and update time should change together. (Some might argue that the applies-from time should be part of the state...)

@ssalonen ssalonen Jul 12, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm what do you think about this AI analysis?

https://claude.ai/share/009bca45-734b-4c29-9d25-eac0eba4291f

I was worried as so much of this happens asynchronously in corr

@mjagdis mjagdis Jul 12, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like a core bug to me. I'd guess the chances of one of the notify or event jobs getting scheduled, starting up and making "enough" progress before applyState sets the update time is pretty slim. But it does seem wrong.

See Core issue 5711 and PR#5712

ZonedDateTime time = (lastStateUpdate != null ? lastStateUpdate : ZonedDateTime.now());

logIfManyQueuedTasks();
if (!(item instanceof GenericItem)) {
Expand Down