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

NSONE: Value None for field '<obj>.tags' is not of type object #2639

Closed
norman-zon opened this issue Nov 21, 2023 · 7 comments · Fixed by #2941
Closed

NSONE: Value None for field '<obj>.tags' is not of type object #2639

norman-zon opened this issue Nov 21, 2023 · 7 comments · Fixed by #2941

Comments

@norman-zon
Copy link
Contributor

Describe the bug

Since updating from 4.4.1 to 4.6.0 I cannot push changes to NS1 anymore.

For any record type I get:

FAILURE! PUT https://api.nsone.net/v1/zones/<zone>/<record>/<type>: 400 Input validation failed (Value None for field '<obj>.tags' is not of type object)

I see there already is a workaround for a similiar problem in the provider.

To Reproduce
Steps to reproduce the behavior:

  1. Push any change to NS1

Expected behavior
The record gets created/updated without issues

DNS Provider

  • NS1
@norman-zon
Copy link
Contributor Author

Ping @costasd

@costasd
Copy link
Contributor

costasd commented Nov 21, 2023

hm. will look very soon, thanks.

costasd added a commit to costasd/dnscontrol that referenced this issue Nov 21, 2023
Latest changes in 2.7.13 seem to be breaking record creation completely, API returns 500.

Whereas 2.7.12 suffers from a bug that breaks creation with 400 due to
mishandling for tags/blockedTags.

Let's downgrade to 2.7.11 that is working and passing the integration suite, for now.

Relates to StackExchange#2639
@costasd
Copy link
Contributor

costasd commented Nov 21, 2023

Confirmed. Seems that the latest version (2.7.13) - and the version before that (2.7.12) is not working correctly with NS1. Will follow up with upstream.

In the meantime, #2642 should create a working setup again.

@tlimoncelli wondering if you have any ideas how we can protect ourselves from such stuff in the future. Even upgrading minor versions can be brittle, so we need to ensure that any module updates run the integration suite for ns1.

@tlimoncelli
Copy link
Contributor

@tlimoncelli wondering if you have any ideas how we can protect ourselves from such stuff in the future. Even upgrading minor versions can be brittle, so we need to ensure that any module updates run the integration suite for ns1.

On one hand, SemVer was supposed to fix this kind of problem. In reality is just makes this kind of problem rare. SemVer isn't an exact science. We should complain to the upstream; they should either revert the brokenness or increment the major version number.

The other way to prevent this in the future is more testing. The GHA workflow doesn't have creds for NS1, therefore the automated tests are skipped. In general I only upgrade the dependencies of providers that have opt-ed in to automated testing. It is the responsibility of provider maintainers to upgrade their own dependencies. Looking at the git log, I violated that rule in 2be618a. Either I misread it or figured "gosh, it's a minor revision... what could go wrong?"

I'll try to do a new release in the next week. (4.6.x)

If you'd like to set up automated testing, I'd need you to create a test (free) account on NS1 and send me ("donate") the credentials. Contact me offline for instructions (tlimoncelli at stackoverflow dot com). Some details here: https://docs.dnscontrol.org/developer-info/byo-secrets (I should update that soon, it is incomplete).

@costasd
Copy link
Contributor

costasd commented Nov 22, 2023

ah excellent, I think I did all of these in the past, outside of sharing the secrets with you 💥. Will go over it again just in case something changed in the config since then and then share the secrets.

@tlimoncelli
Copy link
Contributor

If you would like to set up a test account with NS1, I'll add the creds to the CI/CD pipeline so that NS1 gets tested with every PR. You can use https://transfer.secretoverflow.com/u/tlimoncelli to securely send me credentials.

@costasd
Copy link
Contributor

costasd commented Dec 7, 2023

Upstream bug report ns1/ns1-go#224

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

Successfully merging a pull request may close this issue.

3 participants