Fix deployment sessions creation & counts

[mohamedelabbas1996]

Summary

This PR ensures that sessions (Events) are created and updated when captures are synced for a given deployment (station), so that users inspecting newly synced data immediately see grouped sessions without requiring manual intervention.

List of Changes

• Added utility function deployment_event_needs_update(deployment) to check whether new SourceImages have been added since the last Event was created.

• Used this utility in sync_captures to conditionally call group_images_into_events() only when needed.

Related Issues

Closes #872

Detailed Description

This PR ensures that sessions (Events) are created and updated after syncing captures from a data source. Previously, sessions had to be manually triggered from the admin, which often led to confusion for users trying to inspect newly synced data. To solve this, a new utility function deployment_event_needs_update(deployment) was added to compare the latest SourceImage creation time with the latest Event creation time, and only run group_images_into_events if new images exist that haven’t been grouped yet. This approach keeps session data up-to-date without running redundant grouping operations and improves the overall user experience by ensuring that session information is available immediately after sync.

How to Test the Changes

1. Create a test station (deployment) from the the front-end.

2. Add a data source to the deployment.

3. Trigger the sync job to pull images from the data source.

4. After the sync job finishes successfully:

   a. Verify that sessions (Events) have been created for the synced images.

   b. Confirm that the session's count field has been updated accordingly.

Screenshots

Deployment Notes

N/A

Checklist

• I have tested these changes appropriately.
• I have added and/or modified relevant tests.
• I updated relevant documentation or comments.
• I have verified that this PR follows the project's coding standards.
• Any dependent changes have already been merged to main.

[netlify]

✅ Deploy Preview for antenna-preview canceled.

Name	Link
🔨 Latest commit	113d466
🔍 Latest deploy log	https://app.netlify.com/projects/antenna-preview/deploys/6877d1c5ff2393000856f869

[mihow]

I think this will always be true. Since the timestamps are not updated. There will always be source images created after the event was created.

[mihow]

Two other options

• Run the grouping function without actually saving sessions and use that output to compare the images in the current sessions to the would-be sessions.
• Add a last_checked field to the Event (session) model and update that after regrouping.

I'm okay to postpone those checks and just run the session regrouping at the end of the sync for now.

[mihow]

The regrouping "audit" function would need to be efficient - just fetch the timestamp field from all source images from the deployment and determine the would-be sessions.

See

antenna/ami/utils/dates.py

Lines 98 to 101 in 147183b

	def group_datetimes_by_gap(
	timestamps: list[datetime.datetime],
	max_time_gap=datetime.timedelta(minutes=120),
	) -> list[list[datetime.datetime]]:

[mohamedelabbas1996]

I think this will always be true. Since the timestamps are not updated. There will always be source images created after the event was created.

Good point! thanks for flagging that. One idea I had is to add a small time delta (e.g., a few seconds) when comparing the timestamps, so we only regroup if the newest image was created meaningfully after the latest event.

[mihow]

Remember the create time for an event is the first time the object was created. Same for captures.

Perhaps here is what you meant?

SourceImage.timestamp > Event.end_datetime

Then you’re comparing the time that a capture was captured with the current date range of the session.

Another idea, What if you check and see if the source image does not belong to an event yet?

SourceImage.event = None

SourceImage.filter(deployment=self, event=None)

Or event__isnull=True

[mihow]

Remember the create time for an event is the first time the object was created. Same for captures. Perhaps here is what you meant! SourceImage.timestamp > Event.end_datetime Then you’re comparing the time that a capture was captured with the current date range of the session. Another idea, What if you check and see if the source image does not belong to an event yet? SourceImage.event = None SourceImage.filter(deployment=1, event=None) Or event__isnull=True

…

On Mon, Jul 14, 2025 at 5:45 PM Mohamed Elabbas ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In ami/main/models.py <#898 (comment)>: > + .values_list("created_at", flat=True) + .first() + ) + + if latest_image_time is None: + # No images — nothing to group + logger.debug(f"No source images found for deployment {deployment}.") + return False + + if latest_event_time is None: + # No events exist yet — need to group + logger.debug(f"No events found for deployment {deployment}.") + return True + + # Compare timestamps + needs_update = latest_image_time > latest_event_time I think this will always be true. Since the timestamps are not updated. There will always be source images created after the event was created. Good point! thanks for flagging that. One idea I had is to add a small time delta (e.g., a few seconds) when comparing the timestamps, so we only regroup if the newest image was created meaningfully after the latest event. — Reply to this email directly, view it on GitHub <#898 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABGTX5HFDYS7SZAVGW7XW33IRFJRAVCNFSM6AAAAACBKFTZNCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTAMJYGE3TSNRXHA> . You are receiving this because your review was requested.Message ID: ***@***.***>

[mihow]

Tested and it works!