Fix CrontabSchedule task run before schedule time

[WeJie]

This fix cater the scenairo that crontab tasks(run at every fixed time) with last_run_at is None and start_time is not None run before the scheduled time.

Fix for #912

Unit test included.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.21%. Comparing base (0bac717) to head (88c166f).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #913      +/-   ##
==========================================
+ Coverage   88.19%   88.21%   +0.02%     
==========================================
  Files          32       32              
  Lines        1008     1010       +2     
  Branches      105      106       +1     
==========================================
+ Hits          889      891       +2     
  Misses        101      101              
  Partials       18       18              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[auvipy]

@alirafiei75 would you mind having a look when available again?

[Copilot]

Pull Request Overview

This PR ensures crontab tasks with a defined start_time do not run before that time by adjusting last_run_at and adding unit tests to cover the scenario.

• Added tests to verify crontab schedules respect start_time before becoming due.
• Updated ModelEntry initialization to set last_run_at to start_time for crontab schedules.
• Enhanced tick-based tests to confirm the scheduler heap is not blocked by tasks before their start_time.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
t/unit/test_schedulers.py	New tests covering crontab start_time behavior and heap ordering
django_celery_beat/schedulers.py	Scheduler logic updated to use start_time for crontab entries, preventing early runs

[Copilot]

[nitpick] Avoid inspecting the private _heap attribute directly in tests; instead, verify next due entries through the scheduler’s public API to reduce coupling to its internal implementation.

Suggested change

	assert not s._heap
	m1 = self.create_model_interval(schedule(timedelta(seconds=3)))
	m1.save()
	s.tick()
	assert len(s._heap) == 2
	assert s.get_scheduled_tasks() == []
	m1 = self.create_model_interval(schedule(timedelta(seconds=3)))
	m1.save()
	s.tick()
	assert len(s.get_scheduled_tasks()) == 2

[Copilot]

Using time.sleep in tests can slow down the suite and introduce flakiness; consider simulating time progression by mocking time.monotonic or the scheduler’s time source instead.

Suggested change

	time.sleep(3)
	s.tick()
	with patch('time.monotonic', side_effect=lambda: monotonic() + 3):
	s.tick()

[Copilot]

Patching time.monotonic this way may lead to recursion if monotonic refers to the patched function; patch the scheduler module’s reference or call the original time.monotonic inside the side effect to avoid infinite recursion.

Suggested change

	with patch('time.monotonic', side_effect=lambda: monotonic() + 54):
	original_monotonic = time.monotonic
	with patch('time.monotonic', side_effect=lambda: original_monotonic() + 54):

[Copilot]

[nitpick] For consistency with the surrounding code that uses the local model variable, consider replacing self.model.start_time with model.start_time.

Suggested change

	if self.model.start_time:
	if model.start_time:

[Copilot]

[nitpick] The 365 * 30 days offset is a magic number; extract it into a named constant (e.g., FAR_PAST_DAYS) to clarify its intent.

Suggested change

	- datetime.timedelta(days=365 * 30)
	- datetime.timedelta(days=FAR_PAST_DAYS)