Updating Upcoming Launches, wrt Polar Starlink

[timisenman]

The current next launch has an incorrect date, but the API has been slow to update. I'm not sure if it's a data issue (i.e. has the data been changed or not) or a technology issue (i.e. has an refresh not happened).

If it's a data issue, are we able to go into the manifest and update the data ourselves? For the Polar Starlink launch, the cited source for the launch data is this (https://spaceflightnow.com), but the current date in the DB doesn't match what's in the source. I'd like to be able to reconcile the difference myself, but after a lot of looking, the method for doing that isn't clear to me.

Help here would be appreciated. I've given my customers inaccurate data too many times not to just buck up and ask.

Thanks, Tim

[jakewmeyer]

This specific issue had to do with a name change on the manifest. Previously the name was Polar-Starlink 1, but then the name changed to Starlink 2.1. Without a manual update to the mission name, currently this breaks the auto updater, because there's no unique + unchanging identifier to match on in the row. It's been one of the biggest thorns of using the wiki as a base for updates. For non Starlink launches it fuzzy matches a partial match on the name to be more forgiving, but Starlink launches require strict matching, or it would get confused between (Starlink-31 and Starlink-32), so it has to be a strict 100% match.

Awhile back I asked the team that maintains the wiki if they could add some kind of unchanging unique id to each row, but they refused to add additional columns to the table, even though this would fix the entire issue. This change could've led to auto adding/removing launches from the API as well, but that remains a manual process tot his day. Because any of the fields could change at will, it has to be a best guess effort.

Up to this point I haven't really had a good solution to this, and I can understand the frustration over getting bad data, especially when paying customers are at stake.

At this point, I think the only other solution would be for the API to use launch library v2 as the primary source for time updates. Currently it matches the parsed wiki date to what LL has in their API to match it up with the corresponding LL launch and set's the LL id. If it sounds good to you, I can tweak the auto updater to switch over to use LL for the time updates as soon as the LL id is set.

So the initial date would be parsed from the wiki, but as soon as it's matched up with a launch from LL. all the date changes come from it. This isn't 100% foolproof though, because the LL manifest isn't nearly as far out into the future, so the updates wouldn't start until the launch has a hard date + time. So this wouldn't have prevented this specific issue, but it might help a bit.