Upgrade to The Things Network v3.24.0 (completed)

TTN Announcements
1

Completed: Upgrade to The Things Network v3.24.0

This is a cross-post of an incident on our The Things Network status page.
It will be updated automatically.

Scheduled: Mon, 30 Jan 2023 13:00:00 +0100 until 15:30:00 +0100

Resolved: Mon, 30 Jan 2023 15:30:44 +0100

Affected Components

  • Europe 1 (eu1.cloud.thethings.network): Operational
  • North America 1 (nam1.cloud.thethings.network): Operational
  • Australia 1 (au1.cloud.thethings.network): Operational

Scheduled

Posted: Fri, 27 Jan 2023 17:34:44 +0100

During this maintenance window we will upgrade The Things Network v3.24.0

We do not expect noticeable downtime during this deployment.

Here is the changelog since the current version v3.23.0:

Added

  • List of end-devices can now be sorted by last_seen_at field. Unseen devices will be shown last.
  • End devices now contain lora_alliance_profile_ids field.

Changed

  • serial_number field is now moved to the root of the end device structure. vendor_id and vendor_profile_id are now moved to the lora_alliance_profile_ids.
  • Do not allow to remove the collaborator of an entity if it is the last collaborator (in the Console).

Removed

  • The device version identifiers no longer have the serial_number, vendor_id and vendor_profile_id fields.

In Progress

Posted: Mon, 30 Jan 2023 13:00:51 +0100

Scheduled maintenance is currently in progress. We will provide updates as necessary.

Completed

Posted: Mon, 30 Jan 2023 15:30:44 +0100

The scheduled maintenance has been completed.

2

The incident on our status page was just updated with new information. The first post in this topic has been updated accordingly.

3

The incident on our status page was just updated with new information. The first post in this topic has been updated accordingly.

4

Hello,

My team is using the OpenAPI doc of lorawan-stack (Releases ¡ TheThingsNetwork/lorawan-stack ¡ GitHub) to generate a Client API library and interact with our Things Stack Cloud project.

Today, we have noticed that we cannot deploy end devices anymore with the client because we receive an uncompliant response from the server, it contains a new “lora_alliance_profile_ids” field just as described in your changelog.

Our generated 3.21 (java) library cannot unserialize the V3EndDevice JSON response because that field should not exist.

The 3.24 is not even an official release of lorawan-stack, I am a bit surprised you’re making breaking changes in the API and give no warning nor time to migrate to the right client library version.

How are we supposed to handle compatibility with your products ? And respect our own SLA with our clients ?

Any help would be appreciated.

5

If you are running on a commercial TTI instance, which you should for commercial deployments and SLAs, it’s better to engage with support in stead of using the forum.

1 Like
6

As the JSON is translated from Google Protocol Buffers which drop null/empty/zero fields and the likelihood of changes such as this, making incoming data processing so rigid never ends well, as you have discovered.

Today I retrieved all the fields for a device via the CLI, here’s one of the warning messages I got:

WARN The --all flag is not covered by our compatibility commitment.
WARN This means that it may not work (or behave differently) with future versions of The Things Stack.
WARN Only use the --all flag for development.

Much better to be explicit about what you ask for as fields.

Yes it is, it was announced on all the usual channels. Your link above is to the open source version of TTS, the release files always lag behind implementation.

This is the TTN forum for community users who use TTN, TTI staff drop by occasionally but don’t habitually frequent this place. As such your use of “your” here is inapplicable.

Coding against an API should be able to handle changes on a tiered basis. I create devices using the bare minimum of fields (id, dev_eui, join_eui, app_key, frequency_plan_id, lorawan_version, lorawan_phy_version) and then set settings in logical groups as required, if actually required, the return results should then parse OK.

I do part availability checking against Farnell/Element 14, Mouser & Digikey, the return results are a moveable feast, so this isn’t particularly an unusual situation.

Tiers - against which you implement your systems appropriately so they can always do the core and gracefully fail or part cope with less critical elements.

Or go Enterprise or Dedicated and then you decide when to update.

1 Like
7

First of all, thank you both for your time.

Yes we contracted for a cloud hosted The Things Stack (Cloud plan). I tried to reach their support before using this forum but you’re right.

In fact, the optional or missing fields won’t be a problem but here in Java, the class does not know any “lora_alliance_profile_ids” field and it triggers an exception during unserialization. Java is indeed too rigid for this usecase. My predecessors might have under-estimate this weakness.

As we want to keep the code generated I won’t be able to change the way the call is made (with field mask) or the way the response is unserialized.
It works very fine as long as the server doesn’t do breaking changes or handle backward compatibility.

My concern is that my process relies on lorawan-stack tags and releases. I need this to launch CI and generate my library. It seemed a nice way to handle maintainance and upgrades in my client library and remain compliant with the server, this is the whole point of OpenAPI documentation.
I guess I can only blame myself for this process of CI/CD.

Sorry for my mistake. I was indeed trying to catch the attention of TTI staff. I am doing this on multiple channels.

Yes it seems to be the only good option. But I will have to handle the client library myself and stop generating it.

Indeed, dedicated is what I need to keep the server compatible with my client until I can upgrade it.

Regards.

8

You can ‘hope’ but as they say a strategy based on hope is no strategy…it’s a fact of tech/cloud/software life that breaking change sor even system hick-ups are a fact of life and may be a year, a month, a week a day or even Oh! S4!t not now!.. :rofl: You need to code to adapt per Nick’s suggestions or be agile in your own response as and when…

As noted TTN Forum is often drive by for many TTI Core staff - have you tried the Slack #Support channel - that usually gets quicker lookins and associated responses… :wink: Just did a quick look see and dont see anything from you there…

1 Like
9

How are we supposed to handle compatibility with your products ?

The Things Stack API is controlled by our public compatibility commitment.

We are not allowed to remove items from an API or modify types of fields within the v3.x.x versions (unless for bug fixes of course).
However, adding new fields is completely a valid use case; especially on a new minor version.

Our generated 3.21 (java) library cannot unserialize the V3EndDevice JSON response because that field should not exist.

The Things Stack keeps adding new features and one of the ways we do that is by adding new fields to configuration and messages. Clients should be able to drop unknown fields.

I am a bit surprised you’re making breaking changes in the API and give no warning nor time to migrate to the right client library version.

Once again, adding a new field is not an API breaking change. Modifying the type or deleting a field is a breaking change which we are not allowed to do. Please check the above compatibility commitment for more info.

Once solution here is official SDKs which are in the pipeline.

The 3.24 is not even an official release of lorawan-stack,

A release becomes official when we announce it on our StatusPage. The release artifacts for those who self-host TTS is released after we deploy to TTS CE and TTS Cloud to provide an option to include last-minute bug fixes found after deployment.

I can imagine that users would want to test out new releases prior to the release to TTS Cloud. However, there’s a balance between how much constraint we place on getting releases out v/s waiting for users to run tests.

Indeed, as mentioned above, if you are a customer of TTS Cloud, please reach out to support and our team can work with you on a solution.

3 Likes