Skip to content

China Location Filtering

Overview

The tracker fetcher service implements geographic filtering to prevent location reports from China manufacturing facilities from being stored in the database. This prevents confusion in the frontend and post-processing logic.

Implementation

Location Filter

China locations are filtered at the ingestion point in the tracker fetcher service, specifically in the _store_single_location_report() method of services/tracker_fetcher_2/taskiq_service.py.

Geographic Bounds

Reports are rejected if they fall within these coordinates:

  • Longitude: 73.6°E to 134.8°E
  • Latitude: 18.2°N to 53.5°N

This bounding box covers mainland China and is consistent with the filtering used in the database materialized views.

Behavior

When a location report from China is received:

  1. The report is not stored in the location_reports table
  2. A log message is generated at INFO level
  3. The report is counted as skipped (not stored)
  4. Processing continues normally for other reports

Log Output

When a China location is filtered, you'll see log entries like:

INFO: Skipping report from China manufacturing location
  latitude=22.606683
  longitude=113.8288891
  timestamp=2025-11-03T10:09:30+00:00

Why Filter at Ingestion?

Filtering at ingestion prevents:

  • ❌ Storage of test data from manufacturing facilities
  • ❌ Confusion in frontend dashboards showing trackers in China
  • ❌ Processing overhead for reports that shouldn't be in the system
  • ❌ Geofence triggers for manufacturing locations

Important Notes

check_tracker_activity.py Script

The scripts/check_tracker_activity.py script queries the Apple FindMy API directly, not the database. This means:

  • ✅ It will still show China location reports from Apple
  • ✅ This is expected behavior - the script shows raw Apple data
  • ✅ The database will not contain these reports

This is useful for:

  • Verifying trackers are functional before deployment
  • Debugging connectivity issues
  • Confirming manufacturer testing

Database Views

The database also has China filtering in materialized views (location_history_hourly, location_history_daily) as a secondary defense. However, with ingestion filtering, these view filters are now redundant but maintained for consistency.

Troubleshooting

Tracker Showing in China

If you see a tracker reporting from China in check_tracker_activity.py:

  1. This is normal - the script shows raw Apple data
  2. Check if the tracker is with your manufacturer
  3. Verify it's in a production run that has started
  4. The reports won't be stored in your database

Need to Store China Reports

If you need to temporarily store China reports (e.g., for debugging):

  1. Comment out the China filtering code in taskiq_service.py
  2. Restart the tracker_fetcher service
  3. Remember to re-enable filtering when done

Service Restart

After code changes, restart the tracker fetcher service:

docker compose restart tracker-fetcher

Important Technical Note

The database column hashed_advertisement_key actually stores the KeyPair's adv_key_b64 value, not the hashed_adv_key_b64 value. This naming is historical and must be maintained for the key matching to work correctly.

When Apple returns reports, the service matches using returned_key.adv_key_b64 against the database's hashed_advertisement_key column.

Verification

To verify the filtering is working:

  1. Check logs for "Skipping report from China manufacturing location" messages
  2. Query the database to confirm no China locations are stored:
SELECT COUNT(*) FROM location_reports
WHERE ST_X(location::geometry) BETWEEN 73.6 AND 134.8
  AND ST_Y(location::geometry) BETWEEN 18.2 AND 53.5;

Expected result: 0 rows (after service restart with new filtering)

To verify tracker matching is working, check for "SUCCESS: Matched returned key with tracker" in logs.