Traccar dedup issue. Bug?

I'm running in to a strange issue revolving around deduplication seemingly when volume is very high or when I use httpx instead of curl to load data in to the osmand 5055 receiver. I am running openhaystack to pull data for my FindMy devices then loading that in to Traccar and relying on Traccar for the deduplication piece but lately I noticed deduplication is not occurring. The sequence I can repeat to show the bug is

1. Make new device
2. Send data to Traccar using curl with GET and url parameters
3. Send same data and Traccar successfully dedups
4. Send lots of historical data using python3 and httpx and data is deduped
5. Send same set of historical data using python3 and httpx and data is not deduped although I do see a couple messages about Traccar doing dedup in the stream of about 100 import messages.

After I send the repeated data using httpx it also is now broken for future imports including curl so the entire device now appears to not dedup properly. Very odd.

One difference I see between curl and python3 with httpx are the headers. httpx adds the Connection and Content-Type headers while with curl it's only the default Accept and User-Agent.

I am running Traccar using the timeseries database Docker compose file from the Traccar Github repo and all variables are passed via envs. Thank you for any assistance.

What do you mean by dedup? What configuration are you using?

I am using filter.enable and filter.duplicate to filter duplicate entries. And to be clear this does work great but when I started to send data to Traccar using httpx it's now not showing the message I'm used to seeing and I end up with duplicate entries with same timestamp, lat, and lon.

Typically I'd see this message

INFO: Position filtered by Duplicate filters from device: device1

It all depends on what data you're sending and what order. It can only dedupe with the last message.

Each of my GET requests are formatted in this way.

/?lat=-11.11&lon=22.22&status=0&timestamp=1788781224&id=device1

What do you mean it can only dedupe with the last message? I can create a new device and send a GET via curl with these details and it will dedupe everytime I assume because the timestamp matches another entry for this device? But if I then send a bunch of historical data to the new device using httpx, same url params format, it just accepts all the entries. Should it not see those incoming entries have matching timestamps or am I misunderstanding how dedupe is supposed to occur?

Traccar server log message for when I am sending

2026-09-08 14:54:19  INFO: [Tabcb7081: osmand < 192.168.10.10] GET /?lat=-11.11&lon=22.22&status=0&timestamp=1788781224&id=device1 HTTP/1.1\r\nHost: 10.107.2.71:5055\r\nAccept: */*\r\nAccept-Encoding: gzip, deflate\r\nConnection: keep-alive\r\nUser-Agent: python-httpx/0.26.0\r\n\r\n

It also oddly seems to then be permanently broken for that device and if I go back and send GET requests via curl they do not dedupe.

Incoming positions are buffered per device to handle out-of-order delivery before entering the processing pipeline. The default buffering threshold is 3 seconds, controlled by server.buffering.threshold; setting it to 0 disables buffering. If an older position arrives during buffering, newer buffered positions are delayed so the older one can be processed first.

Positions then go through preprocessing, filtering, storage and event generation. The duplicate filter compares only against the device’s cached latest position: same GPS fix timestamp and no new attribute keys. It does not search database history.

Buffering helps order incoming data, but it does not deduplicate historical imports. Once the cached position has a newer timestamp, replayed older positions can be saved again.

To check my understanding, are you saying if I have a device with lets say 100 points, and I resend the data for that device, only the very last position will be deduped and not the first 99, and thus I will end up with 199 records for said device with 99 of them all having the same timestamp/lat/lon? I did think it was querying the database so that's for clearing that up.

For my scenario is it recommended to adjust the buffering threshold to account for the importing of historical data that can sometimes be 100 positions or more? Any recommendations here so I can send all points every time and allow Traccar to say "no we have seen this timestamp/lat/lon combo for this device already." I'm trying to avoid writing some sort of middleware to pre-filter all of my positions because in the event my query script stops and I have to restart it, I want to send all historical points and not just latest.

What this does not clear up for me is why when I send just a single request does it not deduplicate after the large initial import of historical data?

Thank you very much for your time on this.

The fact that I can recreate is why I get confused

1. make new device
2. send data and device goes green
   curl 'http://192.168.10.10:5055/?lat=-11.11&lon=22.22&id=device1&timestamp=1788781230'
3. do same curl
   curl 'http://192.168.10.10:5055/?lat=-11.11&lon=22.22&id=device1&timestamp=1788781230'
4. logs in traccar properly show "Position filtered by Duplicate filters from device: device1"

Deduping is not designed for what you're describing. It is designed to skip repeated data from devices. It won't help if you plan to re-send duplicate data at some later point.

Ahh so you mean duplicate data within the same buffer time? But why do single messages work? Ah I see if I manually send old data then yes it is NOT deduplicated because it is older than the most recent time. That is what you're describing.

Basically yes.

Okay thank you. I will work on another method to ensure I can send all data in the event I need to grab all available reports but not duplicate ones I already saw.