Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update watched_nses.yml: Remove nccloud.shop NS - NXDOMAIN #8565

Merged
merged 1 commit into from
Nov 7, 2023

Conversation

teward
Copy link
Member

@teward teward commented Nov 7, 2023

nccloud.shop. is now a dead NS, NXDOMAINs. Remove to allow testing to work again.

nccloud.shop. is now a dead NS, NXDOMAINs.  Remove to allow testing to work again.
@teward teward merged commit b957504 into Charcoal-SE:master Nov 7, 2023
2 checks passed
@makyen
Copy link
Contributor

makyen commented Nov 7, 2023

At least for all such issues in the past, we've been just commenting them out, rather than removing them.

It's not clear to me that commenting them out is the right way to go, but it's how @tripleee had been doing it, so I've just continued to do the same thing.

@teward
Copy link
Member Author

teward commented Nov 7, 2023

@makyen understood, but i would suggest that we remove them rather than 'commenting them out'. Ultimately it does the same thing, but if we comment it out and then leave it in her we have large amounts of 'bloat' that we're just carrying from one item to the next. If it's NXDOMAIN, then that means the domain is gone. We should treat it as such and simply remove failing NSes rather than keeping them around. We can always readd them.

@makyen
Copy link
Contributor

makyen commented Nov 7, 2023

@teward Straight removal is the way I'd expect it to be done. I've continued to comment them out, because I keep forgetting to have the conversation with @tripleee to find out the reasons behind the choice to comment them out rather than straight removal. I'm fine with changing to straight removal, but prior to deciding to go in that direction, I'd like to get input from tripleee.

I would note, however, that there have been times when the errors have been intermittent, both within a single test run and over multiple test runs. The intermittent failures within the timeframe of a test run are mostly handled by running test against the whole list and then re-testing any failures and only reporting/failing when a domain fails twice.

The intermittent issues over a longer period have usually only affected specific domains. I had proposed PR #7239 as a way of preventing testing of specific domains that were proving problematic. While I did work on the requested changes in that PR, the need for it greatly reduced as we stopped having problems with the domain that was causing the main issue at that time.

@makyen
Copy link
Contributor

makyen commented Nov 7, 2023

I think I might have over-emphasized the issue. I didn't mean to imply that this should be reverted. I'm sorry that it seemed like that was what I was arguing for. I merely wanted to get input from tripleee, so that we could all be consistent in how these were handled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants