feat: enable new TA tasks on new repos

[joseph-sentry]

Since we don't need to wait for any data to backfill to Timescale for new users we can just start using the new TA task impl.

[seer-by-sentry]

Sentry detected 2 potential issues in your recent changes

Suspicion of a potential technical issue in `apps/worker/tasks/upload.py:758~773` where the result of `commit.get_db_session()` is used directly without checking if it returned `None`, which could lead to an `AttributeError`.

• Description: The code at apps/worker/tasks/upload.py:758 calls commit.get_db_session() and immediately uses the result to perform a database query via .query(). The get_db_session() method internally uses SQLAlchemy's Session.object_session(), which is documented to return None if the object is transient, detached, or not in a session. While other parts of the codebase (e.g., apps/worker/tasks/notify.py) explicitly check if the returned session is None before use, this new code does not. The # type: ignore comment on the db_session variable suggests the type checker flagged the possibility of None. If commit.get_db_session() returns None, the subsequent call db_session.query(Commit) will raise an AttributeError: 'NoneType' object has no attribute 'query'. This would cause the upload task processing this commit to terminate unexpectedly, leading to a task failure or worker process issue. For example, if a commit object becomes detached from its session due to a previous operation or error, calling get_db_session() on it could return None, triggering the failure.
• Code location: apps/worker/tasks/upload.py:758~773
• Suggested fix: Add a check after calling commit.get_db_session() to ensure the returned session is not None before attempting to use it for database operations. Handle the None case gracefully, perhaps by logging a warning and returning early, similar to the pattern in apps/worker/tasks/notify.py.

Suspicion of a potential `AttributeError` at `apps/worker/tasks/upload.py:758`. The code calls `.query()` on the result of `get_db_session()` without checking if it returned `None`, which could happen if the commit object is detached or transient, leading to unexpected task termination.

• Description: The code at apps/worker/tasks/upload.py:758 retrieves a database session using commit.get_db_session() and immediately attempts to query it. The get_db_session() method, which wraps SQLAlchemy's Session.object_session(), is known to return None if the object (commit in this case) is in a transient or detached state. The current code does not check if the returned session is None before calling the .query() method. This will result in an AttributeError: 'NoneType' object has no attribute 'query' if get_db_session() returns None. This specific code path is affected when processing commits where the associated session might be detached or the object is transient. If this condition occurs, the task execution will terminate unexpectedly due to the unhandled exception.
• Code location: apps/worker/tasks/upload.py:758
• Suggested fix: Add a check after calling commit.get_db_session() to ensure the returned session object is not None before attempting to use it for a query. Handle the case where the session is None, potentially by logging a warning and skipping the query or raising a specific error.

_{Did you find this useful? React with a 👍 or 👎}

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.21%. Comparing base (90251ff) to head (fe76dae).
Report is 2 commits behind head on main.

✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #108   +/-   ##
=======================================
  Coverage   94.21%   94.21%           
=======================================
  Files        1214     1214           
  Lines       45022    45030    +8     
  Branches     1435     1435           
=======================================
+ Hits        42418    42426    +8     
  Misses       2303     2303           
  Partials      301      301           

Flag	Coverage Δ
workerintegration	61.63% <100.00%> (+0.01%)	⬆️
workerunit	90.60% <45.45%> (-0.03%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

[codecov-notifications]

Codecov Report

All modified and coverable lines are covered by tests ✅

✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[joseph-sentry]

Gonna wait to merge this until i confirm i fixed timescale