Migrate Regex Triggers for Remaining Package Tracking Goodies to Spice

[pjhampton]

Description

Based on user feedback, the Package Tracker is over triggering, for example - ISBNs.

We need to migrate all triggers from the various existing Package Tracker Goodies over to the Package Tracking Spice as it is capable of determining the Courier for any valid tracking number, and offers actual information about the package status, rather than a link to the courier's website.

With these changes, all queries related to Couriers supported by the PackageTrackr API can be handled by a single Instant Answer.

Once migrated, we will deprecate the Goodies that are no longer needed.

@moollaza has already migrated FedEx, UPS, USPS, and Parcelforce.

We 1 or more volunteers to migrate the five remaining Goodies:

• [ ] CandaPost
• [ ] DHL
• [ ] HKDK
• [ ] IPS
• [ ] Laser Ship

Get Started

• [ ] 1) Claim this issue by commenting below
• [ ] 2) Review our Contributing Guide
• [ ] 3) Set up your development environment, and fork this repository
• [ ] 4) Create a Pull Request

Resources

• Join DuckDuckHack Slack to ask questions
• Join the DuckDuckHack Forum to discuss project planning and Instant Answer metrics
• Read the DuckDuckHack Documentation for technical help

---

Instant Answer Page: https://duck.co/ia/view/package_tracking

[pjhampton]

Anybody interested in this @duckduckgo/duckduckhack-contributors?

[Owlree]

@pjhampton I could take a look at it, but only beginning with next week.

[pjhampton]

That would be awesome, @Owlree. However, I think it would be better to focus on the HTML Entities table for now as it's not common practice to reserve issues. If it's still open when you're done, it's all yours 😄

[Owlree]

Hey, @pjhampton, totally agree—that's why I mentioned next week the earliest, so if anyone can do it sooner, that would be awesome. Just saying that when I get the time, after I get the HTML entities table done, I am willing to take a look at this as well, if no one else does it meanwhile.

[moollaza]

I've started working on this in https://github.com/duckduckgo/zeroclickinfo-spice/issues/3211 -- We'll need a volunteer to port the remaining Goodies though!

[moollaza]

Note: Once we've migrated these, it would be great to add additional regex triggers for the other couriers the API supports that we don't have existing Goodies for.

This website: https://www.trackingex.com/all-couriers.html seems to provide the tracking number format for a large number of couriers. I would imagine most or all of the couriers the PackageTrackr API handles exist on that page 👍

[moollaza]

@Owlree I've taken a first pass at this. Would you be interested in migrating the remaining Goodies?

Basically as you'll see from the current code, you just need to migrate the regular expressions we used to trigger the old Goodies 👍

[Owlree]

Sure thing 👍

[Owlree]

After a first look, those regexes look like a shot in the dark to me. I personally wouldn't use them. Instead, I would use just one regex that would match a superset of them and let Packagetrackr do the job, and maybe cache the response. I think just hand coding every possible regex for every possible carrier is an effort much too big for its small advantage. There will always be some case you didn't think about.

Note that this is mainly what we are doing now, to some degree. UPS matches ^\d{9,12}$, FedEx matches ^\d{12,22}$, USPS matches ^\d{9,30}$. The third includes the first two. There are some other rules, which add alphanumeric characters. This is actually where things get complicated, but I think a more general solution can be found.

By the way, does anybody know how Packagetrackr works? Do they try calling multiple APIs and see which one returns a response?

[moollaza]

@Owlree these regex have been written to match the accepted patterns of the various carriers.

They're not meant to be perfect or exclusive because either way we rely on Packagetrackr to determine which carrier the tracking code actually belongs to. Having the individual regex does help though if we later want to add back the logic that tries to verify beforehand if the potential tracking code is legitimate. I assumed most searches that match those patterns were going to be valid and it seems like they are. However, we can't write a regex that is overly generic or relexed because then we're going to be sending too many API calls. The downside to this is that when we trigger the IA we expect the API to respond and have a result we can use. If this isn't the case we need to fallback to showing something else which slows down the presentation of the results.

It doesn't really matter if we use one regex or multiple, as long as all the goodies are deprecated ASAP in favour of the Spice 👍

[Owlree]

Alright, I'll just port the existing regexes to the spice then.