<@U7QP20JQH> fwiw our testing found ATC working as...
# officehours
z
@seph fwiw our testing found ATC working as expected: https://github.com/fleetdm/fleet/issues/18490#issuecomment-2075600610
s
Thanks for testing it. We’re still working through on our side.
b
I just tried to update to 5.12.1 and think we're also running into this issue when an extension that provides table plugins registers first. Let me know what you all find!
s
Micah dug pretty far. I’m sure it’s a bug, and #8233 was the wrong direction. See https://github.com/osquery/osquery/issues/8323
(those numbers are different)
z
I'm inquiring further with our QA team because we may not have tested with the table plugin scenario: https://github.com/fleetdm/fleet/issues/18490#issuecomment-2088874873
b
Yeah I'm writing up a comment on the issue now - I think I've figured out why this happens too, and it is specifically triggered by table plugin registration
z
Awesome, thanks Brad!
b
Ok left the comment! (cc @Micah Sorenson)
I think another way this bug might manifest if anyone wants to test is if you added a new ATC table to the config on the server dynamically after the client has been running, it wouldn't work
m
Thank you for adding more context on the issue! I started poking around the database init code a little bit ago, but since you’re more familiar with what the fix would be I’ll wait to see your example PR.
s
Zack — no worries about your QA, I think you said y’all didn’t ship ATC tables, so I don’t know that we expected you to catch it
z
I requested that we specifically test ATC though so I want to figure out why we missed it.
We don't ship ATC tables by default but we support configuring them in the product.
s
Ah, yes. Well 🤷
b
OK curious what you all think of this idea: https://github.com/osquery/osquery/pull/8324
Unfortunately I can't make office hours tomorrow, but I am curious if there are any updates / thoughts on this ATC issue and PR then 🙂 It seems like a blocker to upgrading for anyone using ATC so potentially worth a 5.12.2 patch fix vs waiting for 5.13 If we want to de-risk a fix more, another option could be simple revert of #8233 first, then fixing the duplicate error message (which didn't actually block anyone AFAIK) later in 5.13
s
I’m not sure if Micah has had a chance to review yet.
I will create an agenda item to discuss whether we should: • wait to cut a 5.13 “soon” • make a 5.12.2
m
Sorry for the delay, I left a comment on the PR just now in support of the solution. I tested it as well and it fixes all of the failure conditions I encountered while debugging. I really like the approach as it’s not changing anything around initialization.
s
Chatting about this in office hours, I think it’s the only pertinent thing. • We want to get a 0.12.2 cut soon. • doing a narrow revert of the problem PR is easy • But there’s an underlying race condition • So the question becomes whether we have confidence in Brad’s PR (#8324) to put it into a patch release Micah, Zach — Either of you want to review that enough to weigh on whether to put it in a patch release?
m
I feel mostly confident that #8324 will fix the issue without introducing any new ones. However since the initial problem was just that the ATC table attach would create error noise, it may be nice to not introduce this change for one release, while we work towards having the fix more throughly tested for the release after that. Personally I think the safety of not introducing potential new bugs outweighs fixing the ATC table error noise, but I also don’t think this PR would introduce any new bugs.
z
Sorry that I missed this. I do think we should cut the 5.12.2 with just the revert and then I would love to get Brad's work merged for 5.13. I see that you went ahead with this. Thank you!
s
No worries! Stefano and Micah were aligned, so it was easy
z
We are pushing this out to our
edge
channel.
b
Yes sounds good to me too, thanks all! I'll try rolling out 5.12.2 next week as well