Question: Tado integration login error since 2025.3.4?

Sorry, the change is too large to ship in a patch. Feel free to join the beta testing, which starts today.

../Frenck

Tado integration login error since 2025.3.4
### The problem

I cannot login in Tado integration since updating HA to 2025.3.4.
Login at URL works fine.

### What version of Home Assistant Core has the issue?

core-2025.3.4

### What was the last working version of Home Assistant Core?

core-2025.3.3

### What type of installation are you running?

Home Assistant Supervised

### Integration causing the issue

Tado

### Link to integration documentation on our website

 URL

### Diagnostics information

Logger: homeassistant.components.tado.config_flow
Quelle: components/tado/config_flow.py:87
Integration: Tado (Dokumentation, Probleme)
Erstmals aufgetreten: 12:17:17 (5 Vorkommnisse)
Zuletzt protokolliert: 12:26:19

Unexpected exception
Traceback (most recent call last):
 File "/usr/src/homeassistant/homeassistant/components/tado/config_flow.py", line 87, in async_step_user
 validated = await validate_input(self.hass, user_input)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 File "/usr/src/homeassistant/homeassistant/components/tado/config_flow.py", line 52, in validate_input
 tado = await hass.async_add_executor_job(
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Tado, data[CONF_USERNAME], data[CONF_PASSWORD]
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 )
 ^
 File "/usr/local/lib/python3.13/concurrent/futures/thread.py", line 59, in run
 result = self.fn(*self.args, **self.kwargs)
 File "/usr/local/lib/python3.13/site-packages/PyTado/interface/interface.py", line 46, in __init__
 self._http = Http(
 ~~~~^
 username=username,
 ^^^^^^^^^^^^^^^^^^
 ... ...
 debug=debug,
 ^^^^^^^^^^^^
 )
 ^
 File "/usr/local/lib/python3.13/site-packages/PyTado/http.py", line 153, in __init__
 self._id, self._token_refresh = self._login()
 ~~~~~~~~~~~^^
 File "/usr/local/lib/python3.13/site-packages/PyTado/http.py", line 333, in _login
 raise TadoException(
 f"Login failed for unknown reason with status code {response.status_code}"
 )
PyTado.exceptions.TadoException: Login failed for unknown reason with status code 403

### Example YAML snippet

yaml

### Anything in the logs that might be useful for us?

txt

### Additional information

_No response_

Same here. The Tado iOS app and website are both still working fine. Double checked that I'm using the correct password. The integration fails to login since updating HA to 2025.3.4 .

Tado has changed their authentication flow, from password to device flow. This has been patched in the underlying library PyTado and is ready to be merged within Home Assistant. More information can be found here: URL

[Notice] Deprecation/removal of password flow support from auth.tado.com
### The problem

Hi, Mike from tado GmbH. We wanted to let you know that we will be removing support for the password flow on our Oauth server. We will be removing the functionality by **~~15 March 2025~~** **21 March 2025**.

The replacement for this is to use the device code flow (for more info see here or here). This flow is more secure and more appropriate for dealing with use cases where there is limited access to a browser and/or there is no possibility to support the redirect in an authorization code flow (e.g. on the command line, in a script).

This can be used in tandem with the refresh token flow and **must** be in the case that you want to have long-lived access. Our current analysis finds that users using the password grant flow, including those through Home Assistant, do not, in general, use the refresh flow. This causes significant load on our servers because each password check requires expensive hash calculation.

For more information, see also this post on the tado support page.

Note, I've posted this also on the tado client currently being used by HA (see here also with a code snippet).

### What version of Home Assistant Core has the issue?

core-*

### What was the last working version of Home Assistant Core?

_No response_

### What type of installation are you running?

Home Assistant OS

### Integration causing the issue

tado

### Link to integration documentation on our website

 URL

### Diagnostics information

_No response_

### Example YAML snippet

yaml

### Anything in the logs that might be useful for us?

txt

### Additional information

_No response_

Thanks for reaching out, @mgmarino. We'll work this out and keep you posted about any progress.

What's the status of HA being ready for the API being turned off. I saw that URL was cut which includes the new flow changes but I guess some changes on HA side will be needed to be made to accommodate this.

e.g. token + refresh token will need to be stored on HA instead of user/pass due to the OAuth flow changes.

It sounds like we're not ready? Can we reach back out to our Tado contact to let them know and ask for more time?

I have updated the referenced end date to correspond with the most recent communication to the customers (21 March 2025)

Development activities in HA have started. PR is coming. I have aligned with a Core Developer we get Priority on this PR.

PR has been made and already (sub)reviewed with a Core Developer. HA intends to push this in the Beta release, which will be on Friday. It should be included in the 2024.4 release, if I am not mistaken.

Thanks for the update, @erwindouna. We still need to remove the password flow this Friday. We will try to keep the refresh flow associated with this client open until the 2024.4 release. Keeping that open should allow users to continue using HA at least until a restart. For users who are forced to restart, then they should still have the option to use the Beta release.

I can at least confirm that you loose the tado device functions when you reboot today (21st) as other updates require it. Thanks for working this.

@erwindouna Thanks for working on this.
Any idea on when this BETA release would be made available? Because I too lost my access to Tado from HA as previous post, which does break a lot of automation in my HA installation.
Or if you know a workaround I'd be happy to hear it

Unfortunately I don't know another workaround within HA. The refresh token would stay alive long enough when the 2024.4 would go alive. Only those installations that rebooted would potentially be impacted, regrettably.
The Beta scheduled this Wednesday.

Not a workaround per-se, but the Node Red Tado plugin has already been updated and works so you could use that

I restarted HA this morning, unaware of this issue. I didn't relish the thought of being without heading/hot water until Wednesday so I tried downloading the code in the open PR with a view to installing it as a `custom_component`.

Unfortunately for those considering this approach, it didn't work:

`
2025-03-21 09:27:29.593 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry Home for tado
Traceback (most recent call last):
 File "/usr/src/homeassistant/homeassistant/config_entries.py", line 753, in __async_setup_with_context
 result = await component.async_setup_entry(hass, self)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 File "/config/custom_components/tado/__init__.py", line 70, in async_setup_entry
 entry.data[CONF_REFRESH_TOKEN],
 ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^
KeyError: 'refresh_token'
2025-03-21 09:27:33.859 DEBUG (MainThread) [custom_components.tado] Setting up Tado connection
2025-03-21 09:27:33.859 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry Home for tado
Traceback (most recent call last):
 File "/usr/src/homeassistant/homeassistant/config_entries.py", line 753, in __async_setup_with_context
 result = await component.async_setup_entry(hass, self)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 File "/config/custom_components/tado/__init__.py", line 70, in async_setup_entry
 entry.data[CONF_REFRESH_TOKEN],
 ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^
KeyError: 'refresh_token'

`

That would require the latest PyTado as well. Which gives the device flow I built in.

Good point. I guess doing this inside of an HAOS instance is going to be a pig to achieve.

As i understand there is no work around at the moment and we need to wait for the pr to merge? Anything that can be done manualy?

As I understand it, even with the PR merged, this won't be released until HA Core 2024.4 beta dropping next Wednesday, so it's going to be the better part of a week before it's resolved.

Looks like Node Red could be a work-around though.

Well i dont use nodered so i think i will pass that option :p

I'd love to use the local Homekit support, but unfortunately the water heater add on was never supported.

Hi @erwindouna, could you confirm me what is going to be needed when you say: "It should be included in the 2025.4 release"? I am asking because I have a home assistant I would like to avoid updating and I don't know if your words mean that of course I will need to update core version or I will be able to continue with my current version (2024-11) and I will only need to update tado integration. Thanks

This will also impact older versions. Tado had disabled the password flow. I would recommend to upgrade to 2025.4 when it's released.

Thank to all who are working on this but has shown to me the vulnerabilities of some HA integrations. Not a complaint as its supported by very talented but essentially amateur folks. I am shifting to a localised TADO solution from now on.

How? I am interested how you want to get rid of the cloud. Out of curiosity.

They were given lots of notice but now scrabbling around trying to sort it
out. As I said not complaining at all but it's not professional

On Fri, 21 Mar 2025, 21:29 Edwin D., ***@***.***> wrote:

To those asking of non cloud tado use home kit .. it's not fully functional but I run it just in case ... Like now where TADO HA integration is useless until when?

Oh dear... I don't criticise anyone at all. I am just expressing my view
that we rely on a community of amateurs to support this integration. I can
make it work fine locally and have rigged things .. just very disappointed
that after numerous flags from TADO this wasn't addressed until now

On Fri, 21 Mar 2025, 22:01 Edwin D., ***@***.***> wrote:

Peace ... Go your own way xx

On Fri, 21 Mar 2025, 22:01 Edwin D., ***@***.***> wrote:

GitHub - smart7324/homebridge-tado-platform-next: Homebridge plugin for controlling Tado devices
Homebridge plugin for controlling Tado devices

looks like they’ve managed to update the plugin for homebridge to use new oauth method

sure to say 2025.3.4 core didn;t include the integration fix, as I am running it now

The fix is still being developed so not yet ready to deploy live. Also, given that it's a breaking change it's less likely to be included in a patch release.

 URL

That's obvious. But why did Home Assistant inform Tado that they would provide a fix until the password authentication flow is removed?

That’s bad news. It means an integration not working for a couple of weeks😔

I hear you. I completely forgot about it not working and had no not water this morning, much to the annoyance of my family.

I too wanted to get frustrated; yes, this could have probsbly been fixed sooner, and it's going to be a week before the beta is released, then it's going to be another week or two of running a potentially buggy HA Core beta, but I remembered it's just one person maintaining this, in their own time. And I shouldn't have invested so heavily in Tado's ecosystem when I'm so reliant on their cloud.

The best thing we can do right now is try the home kit workarounds, be patient and help the dev(s) with any testing they may need.

How can i workaround with homekit? I tried to add bridge, it's enabled in pair mode but i cant't find it under integration

Try this URL

I had to factory reset my bridge to get it to work before.

I use homekit integration

On Fri, 21 Mar 2025, 21:22 Zvenster, ***@***.***> wrote:

Consider the following:

- This notice of deprecation was sent 4 weeks in advance.
- It took the underlying PyTado library almost 3 weeks to get a first working version released ( URL
- it took them until March 17 to get this stable enough to use. ( URL
- any other library than PyTado and HA was not even informed of this change, they had to hear from others or receive the email 2 weeks ago that this was coming

This meant there was less than 1 week to develop, test and verify for HA.

Source: Ive ported this change to another library (libtado) which i use in my own script, and their maintainer was also *just* in time to get this released. ( URL

With this being a significant change, and also a breaking one, i guess this is how it is, unfortunately.

I get an error “Failed setup, will retry: Error during Tado setup: Login failed for unknown reason with status code 403” since update to latest version on HA CORE. Any suggestions please?

Would love to use the Homekit integration for Tado. There are just a few things missing like the battery status and the current heating percentage.

Had same issue. Removed the Tado integration and switched to local. (Homekit)

If you don't see it come up in HA, just follow the steps via the link below, to factory reset the Tado bridge. (don't worry, you don't need to repair the thermostats or radiators)

 URL

This hot fix did the trick for me and the integration now works:

 URL

If you're using docker, attach to its console

docker ps
docker exec -it /bin/bash

And run the two commands from the comment above.

cd /config
curl -o- -L URL | bash /dev/stdin -d tado -p 140761

This invokes a script that downloads the PR code above and converts it to a custom component in your config/custom_components folder.

Then restart your homeassitant instance, empty your browser cache and follow the instructions to repair the integration. It should work straight away.

@igiannakas it only works if the HA system language is english 😉

@igiannakas thanks, that fixed the TADO integration. After rebooting, I got this message: "Config flow could not be loaded: 500 Internal Server Error Server got itself in trouble", so I did another reboot and the fix finally worked.

Tado not fixed yet for me with this version, anyone any Idea?

Failed setup, will retry: Error during Tado setup: Login failed for unknown reason with status code 403

Here is a workaround for those who are not using Docker:
 URL

I'have the same problem after reboot the Home Assistant. Home Assistant is running on Core 2025.3.3. Reconfig of the integration gifes a unexpected error.

Image

As I commented in the other thread URL , after some failures I was able to trigger the reconfiguration and the new Tado authentication process connecting to HA from outside my network using the HA app on my cell phone.

Same for me…
No login possible for Tado…
Hapend after update 2025.3.4.

if you are running HA OS like me, go to Advanced SSH & Web Terminal and type

/config

and

curl -o- -L URL | bash /dev/stdin -d tado -p 140761

Reboot HA and add integration

this solved everything

Mind to explain what this does? I am surely not applying this blindly

does exaclty what explained here URL
it replace tado integration with login fixeded

Hello
Thank you.
I apply this solution.
I succeded to connect to my tado devices.
Regards

good to hear that the solution works.
will there be a release soon?
or in what time frame will this be in an official release?

Unfortunately it's not working for me. Still having the error and no folder in custom components. Does anyone have an idea, why this error appers at the end ?

Image

The goal is to have this merged in before the Beta, which is scheduled this Wednesday. If all goes well it can be shipped in the 2025.4 release.

workaround with script works for me so far; waiting for the final release. Thx

I applied the workaround. Custom folder created and reconfigure button appeared. Still i have the error " Config flow could not be loaded: 500 Internal Server Error Server got itself in trouble"

Image

@chinezbrun You have to delete tado from HA and reinstall it!

Found out the same. You have to ignore or delete the auto-discovered Tado,
then add a new instance.
Maybe this is something that should be fixed in the PR, but IDK

Op zo 23 mrt 2025 om 17:53 schreef Christian ***@***.***>:

work around also not working for me. Currently using my Node-red flows that I have for back up. Node-Red have new Tado nodes that establish the Oauth link ok. There is a great example flow that shows you how to do it at ( URL

work well.

Thank you so much for your advice, but after two days of tinkering, I haven't achieved anything, and at seventy years old, it seems too late to go back to university.
From what I can see, many of us are having trouble controlling Tado from our home automation app (in my case, Home Assistant). I think Tado has set the bar too high for many of us with this new process.
I don't even know where to enter the calls. I've typed them into the "Terminal" in Home Assistant, reset them, and haven't achieved anything.
Anyway, thanks everyone. I'll keep trying.

We're aiming for a Beta release on Wednesday. Please keep notified of this thread and I hope we can resolve this for you all as soon as we can!

Check if you have the Terminal installed. If so, it will appear in the Home Assistant sidebar.

Image

If not, install it via the Add-on Store:

Image

Run the Following Commands in the Terminal

Open the terminal and enter:

cd /config

curl -o- -L URL | bash /dev/stdin -d tado -p 140761

⚠ Note:
Sometimes, the entire command may not paste correctly into the terminal. If that happens, try pasting it again carefully.

Restart Home Assistant
After running the command, restart Home Assistant once or twice for the changes to take effect.

Again, thank you very much for your collaboration.
I'll wait until Thursday, because I'm afraid I might mess it up more and more. Actually, I only have one schedule that will turn on the heating at off-schedule hours if it's very cold outside. I can schedule the rest directly from the MyTado app.
I've even deleted the Tado integration, and as some have commented, I haven't been able to reinstall it. Even after Thursday, I have my doubts about having a Tado token, which I presume I'll need to reinstall the integration.
I do have the Terminal in the sidebar, but after deleting the Tado integration, I don't know if the command will have done anything.
Again, thank you very much: Kepa

Rest assured, once the patch becomes available you will be provided with user friendly steps to authenticate with Tado again. On the background the tokens will be obtained, stored and refreshed accordingly as you were used to. I hope you can manage in the main time, if you prefer not to run the work around.

Workaround doesn't work for me :( I get:

ImportError: cannot import name 'AddConfigEntryEntitiesCallback' from 'homeassistant.helpers.entity_platform' (/usr/src/homeassistant/homeassistant/helpers/entity_platform.py)

I've this error during authentication:

`UnboundLocalError: cannot access local variable 'tado_device_url' where it is not associated with a value
`

Great! It worked after following the above procedure via Terminal, restarting HA, and logging back into TADO. You did a great job.

After the failure, however, I'm now suspicious.

I use a TADO Smart IR Remote Control to control my DANYON split air conditioning system via HA.

Do any of you know of another cloud-free solution for this?

@lehmanro2

You can use the homekit integration to install the "Smart AC Control V3+" in Home Assistant.

I've just been researching what Smart AC Control V3+ is. Also from Tado. I'm jumping out of the frying pan and into the fire.

**A copy from the Pull Request**

The fix has been merged and this means it will be made available shortly! The earliest possibility will be in the **Beta**, on **Wednesday the 26th of March**. For those we didn't felt comfortable or were unable to get the custom component fix in (provided by @Dillton, again thanks for your great work around!), this is the easiest way to get the new code.
The other opportunity will be the release of **2025.4.0**. Currently this PR is still qualified to be part in this release.

**How to opt-in for the Beta?**
First a short disclaimer: it's a Beta. Please treat it like a Beta. It might show some instabilities and hick-ups in parts of Home Assistant.

1. Go-to your system settings:
image

2. Go-to updates:
image

3. On the top-right, find the three dots and click "Join Beta channel":
image

4. Confirm to join the Beta channel:
image

**I have installed the custom component/work around. What should I do?**
You **have to** remove the customer component/work around. Why? The custom component will also be the first referenced to be used. Effectively meaning if you don't remove it, the _old code_ will always be called and future updates of the Tado integration will not be made effective. If this is what you intend, feel free to do so. If you wish to get back on track, you _have to_ remove the work around.
Please use the following command in your terminal:

et me close of with thanking all the collaborators who were very eager to tinkering a long and find solutions and being very supportive to help other users! A great example, even in a dire situation, how the Open Source community tries to help each other!

Let's now focus on the Beta and onwards to the official release. Feel free to ask for support in this thread, which I will monitor to help around as best as I can. 😃

One question regarding the timing of the removal of the custom component. Does it matter when this needs to be removed, i.e. before or after the 2025.4 upgrade ? I would think first remove the custom component and then do the update to 2025.4 and it should all work fine.

I would recommend to "clean" your installation, yes. So remove the custom component prior to upgrading.

This person is a legend, worded like magic. Thank you to all who keeps this stuff running.

I have two instances of the Tado integration (two homes). I did what's described here and it worked with the first instance: it asked me to click a link which took me to a tado login web page, where I had to type my credentials. However, when I tried to do the same for the other instance, it took me to the same page but didn't ask for the other home's credentials. Both integrations are showing as correctly working, but the sensors and entities related to the second instance (for which I wasn't asked to login) don't work.

Then Tado think's you're logging in with the same account. On the authentication page you should be able to switch accounts. This is something that is managed on Tado's side _how and on which account you login_.

Ok, so how do I force home assistant to present me with the login link again? It thinks I’m logged in but I’m clearly not

You could enforce a "Reload" on this particular instance and see if this enforces a new login step. If you're very tech savvy: you can goto `/config/.config_entries` and find the particular Tado instance. Remove the attribute `CONF_REFRESH_TOKEN` and the integration should automatically provided a re-authentication.

Other than that, I haven't included a reconfigure step in the current code. Might be a good addition for a later phase. In the worst case scenario, delete the instance and rename the entities once they're loaded back in.

"Reload" just "reloads successfully" without asking for login. Unfortunately I am on Home Assistant OS, so I cannot access the config folder

@mgmarino while I appreciate the support, the lead-time for this breaking change was _very_ short, leaving users of the stable HA release train with non-functional Tado support, at least until 2025.4 is released (which is not available yet). Having support for the new auth flow this quickly in HA is already impressive, but one month of notice is simply way too short to allow for a smooth transition.

I use a HA docker installation and have two instances of Tado with a lot of entities (80+) - the mentioned workarounds and fixes do not work for me and I am not able to join the beta channel. Any solution for my case too?

Thanks soo much for your great work and for keeping it alive :-)

When I try the workaround I get `[%key:common::config_flow::abort::already_configured_account%]`. I believe it's probably because I disabled but didn't remove my old config before trying it but now all Tado entries are gone for me to delete it.
Any ideas?

Quite strange that this was announced 6 weeks ago and that we need to wait for the next major monthly HA release. In my honest opinion this should already be pushed in a HA fix release as soon as possible. We are talking about an essential component that controls the climate in your home, not a fancy nice-to-have thingy. Each day your users are raising new tickets for this blocking issue. Thanks for the hard work though.

@groenmarsmannetje 6 weeks is a ridiculously short amount of time for Tado to announce a major breaking change. The reasons you described (essential component, used by many) is the exact reason it shouldn't be rushed and we make sure it is solid before reaching production.

You must remember that HA is a free, open source platform maintained by a community. It's likely the person updating this is doing it in evenings and weekends, unpaid.

Well ... the current solution is not solid .... because it is not working at all ;-)

I agree this should be pushed in a fix update, but you should also get off your high horse @groenmarsmannetje. This is free software and you're not entitled to anything.

It is not totally free.... I pay a monthly fee... to support HA and the community. I am giving "customer feedback" for free, maybe good to just listen to what your users tell you, it might be that you could learn something from it for free ;-)

You pay a monthly fee to a commercial company, Nabu Casa, for their product, Home Assistant Cloud. They pay some people who work on home assistant, but not the person that owns the Tado integration. The HA Devs did nothing wrong here, this was entirely Tado's fault.

Sorry, the change is too large to ship in a patch. Feel free to join the beta testing, which starts today.

../Frenck

Well, at least it is a (another) reminder that cloud-requiring hardware is just not reliable enough if you want to avoid these manufacturer surprises :)

Is anyone aware of a open solution to control these sub-1GHz 6LoWPAN thermostats?

Sorry mate, but things like these makes me want to quit all my open source projects. Even though (I assume) your intentions are good, you cannot expect them to throw any principles over board by shipping such a big change as a hotfix just because some random vendor decided to introduce a breaking change like that. In fact you cannot blame them either as they do not support things like the tado integration officially. Indeed it is still based on a reverse engineered api, so Tado was just being nice by giving 6 weeks of time.

Again I feel like your intention is good, however your message most certainly hurts those trying to provide free software all day every day. Lastly I want to mention that HA's release cycle is 1 month (which is already interestingly short given the amount of testing that must be done to ensure everything works even with custom integrations). In the end, you do have a solution as of now as you can use the beta software which includes the fix. As @accumulator said a local solution would be even better. In fact I already spend around 3 months trying to reverse engineer the commands send by the bridge to and from the thermostats. Quite an effort, but when I'm successful, one _might_ be able to use an esp8266 acting like the bridge. At least I'm already able to turn em on and off locally 🤷🏼

Thank you so much, "orangecoding," for your comment. **Please don't leave!**
What would become of us who don't master coding languages and survive thanks to visual editors without those of you who master coding languages? What would we be without those who voluntarily contribute a portion of their time and dedicate that time and their best will to all of us?
Without you, open source would be nothing. Instead, it's more than just code. **It's a philosophy.**
Thanks to all those who promote open source.
Best regards: Kepa

Thanks @Kepasub
It's good to know there are still people out there that doesn't take all of this for granted. To be honest I cannot blame anybody. Society has changed to become an ever growing crowd of people expecting free stuff is just around the corner. It's pretty frustrating to spend weekends on solving a problem and then get bombarded by random strangers insulting me for not fixing things earlier. Anyway, I'm side-tracking this thread, forgive me ;)

TLDR; For those that needs a fix now, go with the beta, for those who can wait, it's only 7 more days until it's release day.

I think what may have frustrated most of those affected is that we only found out when our HA boxes restarted after applying the 2025.3.4 update on/after the 21st March.
If we'd known that a restart was going to stop HA talking to Tado we would have probably held off until 2025.4 came along.

I know it was unrelated to the HA update. But it was the restart that stopped it working. If we (the Tado users) had held off updating and therefor not restarted our HA, then I think our HA would still be talking to Tado.
The 2025.3.4 update just happened to be released around the 21st March when Tado turned off that authentication method.

"We will try to keep the refresh flow associated with this client open until the 2024.4 release. Keeping that open should allow users to continue using HA at least until a restart"

This is what Tado wrote above. The update triggered the reboot and this prevented the integration from continuing to work.

Unfortunately that's not what actually happened, and thanks to HA we have all the traces to check this 😆
I lost all Tado data on 21/03 15:24 (CET), while my HA hasn't been rebooted between 17/03 19:14 and 22/03 10:50 (which is the time I updated to 2025.4).
So in my case at least the Tado integration lost access to the platform completely out of the blue, while I was at work.

The long awaited Beta is out! Details can be found here: URL

I hope this brings the stability and ease of use to solve this issue. If you encounter any trouble, please use the Beta issue tracker: URL

After my installation got broken last week, I decided in the end to just control temporarily directly from Tado app and just wait for the BETA.

This morning, the BETA showed up in my updates, I installed it and immediately got a fix notification for an expired Tado Authentication.
Once I clicked submit, I received a new message with the OAuth link, but also the token separately (in case it would not get filled in automatically).
I followed the link to the Tado OAuth and confirmed with my Tado login and that was it.

Issue fixed, without having to mess around too much with custom integrations from CLI and such. Happy Days!

A big thanks to @erwindouna for his hard work, and to the community for testing and confirming different solutions and workarounds, even if I chose not to use them.

To those getting so frustrated, come on, lighten up, there really are much worse things in life that waiting one week for a software fix.
(which, by the way is incredibly fast -again props to Erwin for that-, even if you count the whole period being less than 2 months., it's still very fast)

Small Update on my previous post: If you do a "Restart Home Assistant" your authentication will expire and needs to be renewed.

This isn't intended behavior. I made it persistent so the refresh token is saved and can be reused upon a restart.
I just checked again on my local setup and this works this way.
Do you have logging?

You might want to consider sponsoring @erwindouna (a one-time donation option is also available). I just sent some money—huge thanks for all the effort!
 URL

I installed the beta version and can confirm that the fix works. The re-authentication worked without issue at my side. Thanks for all the effort!

Not necessary to do my work. Nonetheless your gesture is greatly appreciated!

@erwindouna it happened this morning, maybe half hour or so after initial install, when I ran a restart as I had been tinkering a bit. (unrelated config). However, I just tried to reproduce it with debug logging enabled, and it staid persistent now.
I saw there was an update BETA as well, so thought I'd try that one at once too and still persistent.
Must have been something funky this morning

That's a new leas for me. So every new fresh installation the persistence is gone. Again, this is not intended behavior but a good lead for me to investigate. Thanks!

Maybe not always: as in my previous post, I successfully upgrade to the b2 yesterday and also did a restart in an attempt to reproduce.
Maybe, it's only the first time that it happens, for some reason?

I think the token is only valid for about 10 minutes. I wonder if this is just bad timing - token nearly expiring when you restart so by the time it's restarted and refreshed the token it's timed-out?
Is it possible to force a token refresh on shutting down HA?

I have gotten information about the strict security of the refresh token. It comes down that the reusage of the refresh token is secured in such away that it may not be reused multiple times in a refresh token flow (this is a prevention for stolen refresh tokens). If the OAuth server detects this potential threat, it will log out.

Basically this means if the refresh token is not expired yet and it's being offered multiple times (twice as I understood) to re-authenticate - in the case of a reboot - it will be made invalid and the user has to actually re-authenticate via the offered flow within HA.

Either wait for 30 days when the refresh token expires (keep track on when you first logged in) or accept when you've done multiple reboots within the 30 days you have to go through an actual re-authenticate, simply because Tado secured its login very well. :)

I can tinker along and see in alignment with Tado what can be done, yet I won't give it an enormous high priority - since this is intended security from Tado and we should not interfere with it. In this worst case you need to hold your horses and not reboot daily or accept you need to re-authenticate if you ask for a refresh token too early in a row. :)

That sounds eminently reasonable. A small update to this effect in the documentation would suffice

Good point. I will adjust the documentation. 👍

Let me break it down in a _normal flow_ and _refresh too often flow_:

**Normal flow**
1. You authenticate with Tado and HA obtains an access token and refresh token.
2. The access token is used in every single call we make with Tado (to fetch data, to set new states, etc.). The access token is only valid for 10 minutes. The refresh token is valid for 30 days after issuing.
3. If the access token is about to expire, PyTado will detect this 30 seconds ahead before expiration (this is to prevent you as a user run into nasty situations 😉) and it will use the refresh token to obtain a new access token (again, valid for only 10 minutes). This cycle will continue on and on, as long as the refresh token is still valid.
4. If the refresh token is about to expire, PyTado will detect as well 30 seconds ahead before expiring. It will then ask Tado for a new refresh token to be used. This cycle continues on and on, but simply happens on the background every 30 days.
5. From this point on, if nothing happens that breaks these tokens (forced logouts from the OAuth server, whatsoever), you have no interference at all and should not have to re-authenticate anytime soon.

**Refresh too often**
All steps above apply, where the caveat is in step 4. If you ask for a new refresh too often (twice according to my current understanding) within the expiration period of 30 days, the OAuth server of Tado marks this as _suspicious_. Why would a user ask for a new refresh token multiple if its current one is still active? It might have been stolen. It's a prevention.
This behavior can be triggered if you reboot you HA instance multiple times within the 30 day period. Why? Since within HA we store the refresh token to make that persistent and help you out and not require you login with Tado each time you login.
I don't store the access token within HA (only in the memory of the runtime). Simply for the reason it expires so quickly and serves no other purpose.

Again, this is what I currently understand of the workings of the OAuth server of Tado. My basic advise for now would be, don't try to reboot unnecessarily if you find the re-authentication annoying. Otherwise, accept the excellent steps we provide in HA to seamlessly re-authenticate you with Tado. 😄

Update in docu should also suffice for me. It being an effect of a security feature, is only good news. In the end, having to quickly re-authenticate is not what one would call a "big deal". (definitely, because it would only happen when you're working in HA anyway)

Race conditioning is what I believe applies here. The same refresh token is used twice or more, it will automatically logout, from the information I received from an insider.
Frankly speaking my explanation doesn't stand. When I rush multiple reboots, the same refresh token should be offered it lastly obtained. Yet, not re-authentication is enforced on me.

If you can share the logging that you can obtain and elaborate the steps you're doing, I might be able to reproduce it and understand better what's causing it. :)

I have to make a rectification here. It's more due to multi threading. I'll look into it.

With 2025.4.b8 on 2 different instances I get Error 500 The server got itself into trouble.

Log shows:
PyTado.http :: ERROR :: Failed to refresh token, probably wrong credentials. Status code: 400

On the beta instance I removed the integration, there I get this error while trying to add the discovered integration:

 File "/config/custom_components/tado/config_flow.py", line 85, in _wait_for_login
 await self.hass.async_add_executor_job(self.tado.device_activation)
 File "/usr/local/lib/python3.13/concurrent/futures/thread.py", line 59, in run
 result = self.fn(*self.args, **self.kwargs)
 File "/usr/local/lib/python3.13/site-packages/PyTado/interface/interface.py", line 99, in device_activation
 self._http.device_activation()
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
 File "/usr/local/lib/python3.13/site-packages/PyTado/http.py", line 554, in device_activation
 if self._check_device_activation():
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
 File "/usr/local/lib/python3.13/site-packages/PyTado/http.py", line 545, in _check_device_activation
 raise TadoException(f"Login failed. Reason: {token_response.reason}")
PyTado.exceptions.TadoException: Login failed. Reason: Bad Request

@mgmarino thanks for helping the awesome opensource devs on their way here and also kudos for notifying the community.

I would like to mention, as feedback to the Tado company the following:

probably many (at least me) bought the tado because of the home assistant integration. So I'd assume there is plenty of support coming to tado from this community and you as a company most likely know that.

In that light, I feel the deprecation notice on an active user base of about 5 weeks is ridiculously short.
At the moment, a large amount of users have impact on their automations in their homes.

For example, in my 5 person household, everyone knows how to use home assistant, but none besides me have the tado app. Yes, we have a physical fallback for manual control, but our automations are now gone.

I understand that Tado supports their own app, and the API might be more of a tinkering thingie, but in light of a vibrant ecosystem with many users that support Tado and their hardware, I feel this is kind of a let down.

Basically, because of a performance issue in the password flow, you gave 5 weeks notice.

In my opinion, this could have been handled with more time in reserve (arbitrarily, 3 months seems a minimum) to not burden the community and the developers that spend their spare time for this integration.

All in all this is a hasty decision, with loads of pressure on this community if I read the threads right, with a lot of synchronization with core HA devs, who can probably spend their time better on cool stuff, than dealing with a badly managed deprecation schedule from TAdo.

@mgmarino nothing personal against you of course 👍

Maybe Tado could help out a bit by giving the devs working overtime on this a bit of extra love, I already see a link asking for this here URL

thanks for listening

@chinezbrun Can you expand on what exactly you did? I run HA in Docker as well. i would really appreciate it. :-)

Just install the fix, clearing the browser cache and restart HA. But, I understood that 2025.4 will have the fix :).

Seems like issue is fixed with the latest HA update(Core 2025.3.4, Supervisor 2025.03.4, Operating System 15.1).

I've updated to Core: `2025.3.4` (Docker Container) and Tado is blocking the startup of HA in `Initializing` state

It seems to be blocked on timeouts for HTTP requests originating from the Tado integration:

bash
 File "/usr/local/lib/python3.13/site-packages/PyTado/http.py", line 166, in _log_response
 f"\n\tData: {response.json()}"
 ~~~~~~~~~~~~~^^
 File "/usr/local/lib/python3.13/site-packages/requests/models.py", line 974, in json
 return complexjson.loads(self.text, **kwargs)
 ^^^^^^^^^
 File "/usr/local/lib/python3.13/site-packages/requests/models.py", line 926, in text
 if not self.content:
 ^^^^^^^^^^^^
 File "/usr/local/lib/python3.13/site-packages/requests/models.py", line 902, in content
 self._content = b"".join(self.iter_content(CONTENT_CHUNK_SIZE)) or b""
 ~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 File "/usr/local/lib/python3.13/site-packages/requests/models.py", line 826, in generate
 raise ConnectionError(e)
requests.exceptions.ConnectionError: HTTPConnectionPool(host='54.170.199.124', port=8080): Read timed out.

If I try to `curl` that address I seem to get a `200 OK` but the request never returns, just blocks _(maybe normal/maybe not)_:

**tim@raspberrypi:~ $ curl -v URL
* Trying 54.170.199.124:8080...
* Connected to 54.170.199.124 (54.170.199.124) port 8080 (#0)

* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Length: 9442375
< Content-Type: application/json
< Date: Tue, 01 Apr 2025 20:06:50 GMT
<

Got to CTRL+C here to get back to my shell

Tado has deprecated an authentication method we used on the background. It has been patched and is available in the Beta if you need it urgently. Tomorrow the official release will be shipped which will also contain this fix.

I just updated;

Core 2025.3.4
Supervisor 2025.03.4
Operating System 15.1

What do I need to do to re-establish auth between HA and Tado? I tried clicking the "reconfigure" on the integration, and then provide my password, but I am getting "unexpected error"

Image

@mgmarino quick thanks for taking the time to post the deprecation notice in here - much better than just silently deprecating the login flow.

Everyone who's been working on a fix, likewise, big ❤

Sounds hopeful ... is this a fix for both Tado legacy and Tado X devices? (right now my legacy devices are working fine with the current beta, but not the X devices).

For Tado X you can apply the fix mentioned above on top of 2025.4, this works for some but let's verify the final version.

On Wed, Apr 2, 2025, at 17:06, Edwin wrote:

Jelmer Koekkoek
0649883184 | ***@***.***

A big thank YOU to everybody being involved to make it working again. My HA-Docker just restarted the new April-Release AND Tado is working again!!! Hurra!!!

I updated to 2025.4 and want to install the tado integration. My question is: do I need to install the custom integration first or can i add tado without it?

Custom integration was a workaround until 2025.4 was released - no need to install it now

Thanks to everyone who has volunteered their time to help others.
I haven't received version 2025.4 yet.

I've got 2025.4 and my Tado X is still not working (Tado 3+ in another location is working fine). What do I need to do? Someone mentioned a fix/workaround until a permanent fix is included, but I can't find it.

Thanks so much to all the developers and testers!!

Do we need to remove the custom integration iow the work around before installing the core component ?

Thanks again to everyone who has volunteered their time to help others.
I've already received version 2025.4, and the integration (I had deleted the previous one) worked perfectly.

thanks for all the hard work and to everyone who has worked on this.
Integration asked for new device authentication flow and everything is well again 👍
Thanks again!

A quick fix for me, at this point running HA in Docker, was to change the image-tag from stable to "2025.4".

After updating, HA showed an error message that Tado authentication were put of date. Now I re-authenticated tado and everything is working again.

I'll change it back to stable once 2025.4 is considered the stable version.

Then you need to put back in the custom component that takes care of the Tado X. It's not supported in the default integration, yet. :)

can you give me the link and the instructions on how to do that?

I still have the config flow 500 error when I try to add Tado back again, any tips on how to solve? Running the latest 2025.4 version of HA.

Hi @erwindouna,

Thanks for all the work on this. I have asked before but did not see an answer so maybe it got lost in the many posts here.

In the merged "Tado migrate to OAuth Device Flow #140761" you mentioned to remove `rm -rf /config/custom_components/tado` the temporary custom tado integration when updating to 2025.4.0. Is this still applicable or do we just update as is?

thanks in advance.

You need to do this if you have the custom integration installed, if not then you can update as normal.

I can also confirm that authentication works now after upgrading to 2025.4.0.

Same here. It works now after updating to HAOS 15.1 and Core 2025.4.0.
Thank you so much for all the good work 👍

Hallo zusammen, besten Dank für die sehr gute Arbeit. Mit OS 15.1 und Core 2025.04 ist auch bei uns das Problem gelöst. 👍

Yea, same here +1.
Very impressive that you guys manage to get a fix live with the official release, considering how short that deprecation notice was. 💪

Update also brought my Tados back - thanks to the team for fixing this under such time pressure!

I disagree. It still doesn't work out of the box for Tado X, which needs a workaround to make it function correctly.

Unfortunately TadoX support requires a rewrite of PyTado which is happening (but taking time) but is not part of this OAuth change. TadoX was not supported before either.

@EACourts you can track Tado X progress in the library in this issue URL

I'm sure HA support will shortly follow after that's closed

Hot working for me :( I've tried thte workaround but I continue to get an error:

Image

and I cannot ignore it

I removed everything, reboot:

Image

Image

nothing happens :(

latest version:

Image

Do a hard refresh of your frontend with CTRL + F5. That should load in the strings for this part of the autehniciaton.

Same here.
My TadoX was working with the custom component but has been broken by the latest HA update. I've tried it with and without the custom component but the problem is the same - when I try to configure it I get a white box titled "Tado" with a never-ending rotating circle.
A previously configured Tado V3+ continues to work fine.

Hello,

I still have problems with the Tado integration.
After a reboot of the Home Assistant I have to log in again regularly.
I have reinstalled the integration, but the problem remains.
Did I miss something, do I need to do something else?

Image

If you have Tado X, stop trying, the custom component is not working properly after an update and needs a lot if tricky stuff to get it to work again after every update. I stopped trying and waiting for the full support by default

For reference, I do have Tado X working on the latest Home Assistant version using the custom component from @dmho.

At some point after a Home Assistant update, Tado became unauthenticated for me. To fix it, I went through the auth process manually using the link from Developer Tools (since the UI was stuck on a loading screen when I tried to re-authenticate).

Image

This workaround has kept Tado X working for me so far!

This has worked for me too. I was wondering if it even NEEDs the custom component?
The only problem I have is that I need to re-authenticate Tado after every reboot or update of HA, which can be quite often.


Question: Can't add FirefoxPWA's patched Firefox.app into filtered applications?

I'm pretty late because I didn't have much time. Anyway, I tried doing this but it doesn't work for me. It appears the executable does not see variables set in `LSEnvironment`, so the app cannot start.

Apparently `LSEnvironment` by processes started via "Launch Services" and not via terminal (source?). However, it also does not work for me when I try to launch it from Launchpad. Maybe it's because I'm using the old macOS 10.15.7 (the latest I could install into VM)? But in any case, I would like if launching from the terminal (using `firefoxpwa site launch` and `open`) would also work.

Is there any more reliable way of setting environment variables for a bundle? Or, is `swiftc` included in standard macOS out-of-the-box? This isn't the nicest solution, but maybe PWAsForFirefox could compile a new executable when installing each PWA and include `exePath` and `pwaId` directly in the source code.

Can't add FirefoxPWA's patched Firefox.app into filtered applications
FirefoxPWA is a way to install PWA as an app with Firefox. On macOS, it downloads a separate instance of Firefox to ~/Library/Application Support/firefoxpwa/runtime/Firefox.app, and patches the binary to do some additional magic for PWA to work. However, I'm not able to add this Firefox.app into filtered applications, so I'm seeing many ads.

### Steps to reproduce
1. Install FirefoxPWA's extension as well as the native counterpart (via Homebrew on macOS)
2. Create a PWA with it
3. Try to add the patched Firefox.app into filtered applications

### Expected behavior
The separate, patched Firefox.app should be added to the list, and filtering should work

### Actual behavior
The app is not added to the list and filtering is not working. AdGuard instead highlights the original Firefox.app in the list, which locates in /Applications/Firefox.app, as if they're the same one, but they're not.

Then I tried adding the PWA app it creates in ~/Applications (for example ~/Applications/Spotify.app) into filtered applications. It showed up in the list, but the ads are still not filtered this way, so I think being able to add that patched Firefox.app is the key.

Finally I granted AdGuard full disk access then retried, but it doesn't work. And I tried trashing the original Firefox.app & delete its entry from the list before adding the patched one. It did show up in the list this way, but filtering is still not working.

### Customer ID
Not seeing a "Customer ID" in the email reply? Ticket number is 554896. Or is it this strange string at the end? -> [X7LYQM-557Q]

### Your environment
* Environment name and version: Firefox 94.0.1, macOS 12.0.1
* Any specific potentially conflicting software installed: LuLu firewall

Hello there!

The impossibility of filtering PWA apps is due to the way the FirefoxPWA solution is implemented. We have opened an issue.

The original Firefox.app and the patched Firefox.app are the same from the point of view of the system, since they have the same bundle identifier. You can see it visually as follows:

1. Set the original Firefox.app as the default browser
2. Delete original Firefox.app
3. Perform an action that should open the default browser.

The patched Firefox.app will open.

Thanks a lot for the explanation and opening the issue there! Will be keeping an eye on it 👀

Change the way the final PWA app is formed on macOS
### Problem Description

AdGuard can't filter PWA due to the way PWAsForFirefox generates the executable for the PWA application.

### Proposed Solution

The most preferred way is to replace the script with a real executable binary file.
This is a simple example source code for an executable.

import Foundation

let exePath = ProcessInfo.processInfo.environment["exePath"]!
let pwaId = ProcessInfo.processInfo.environment["pwaId"]!

let task = Process()
task.launchPath = exePath
task.arguments = ["site", "launch", "--direct-launch", pwaId, "\"$@\""]
task.launch()
task.waitUntilExit()

In order for the updated environment to be detected by the process, it is necessary to make changes to the info.plist file by adding the following lines there.

 LSEnvironment

 exePath
 /path/to/firefoxpwa
 pwaId
 PWAID

### Additional Information

I tested this solution, it works fine.
The executable file was compiled using swiftc, after that I replaced the original executable with my executable and modified the info.plist file.


Question: Can't do mkltfs on HP StorageWorks Trivium 3000?

Yes. But the alternative is to use /dev/nst* instead. `nst` device never issue `REWIND` at open/close.

Another point is to add `-o eject` option to LTFS for a safeguard. Basically LTFS tries to use `append only mode` of IBM drives. But the `append only mode` only can clear when the tape is ejected from the drive spec. So LTFS only uses the `append only mode` when `-o eject`. Because historically default behavior is keep the tape on drive at unmount, so it is no chance to disable the `append only mode`. (May be it is a good timing to consider to change default behavior...)

Anyway, you can avoid data corruption because of `REWIND` from another path if you add `-o eject` in the command line. But you may receive an write error (and goes to R/O mode) when `REWIND` from another path happens.

Can't do mkltfs on HP StorageWorks Trivium 3000
Hello.

I've compiled LTFS using manual in README on my Debian 11 Bullseye (Linux 5.13.19-2-pve #1 SMP PVE 5.13.19-4 (Mon, 29 Nov 2021 12:10:09 +0100) x86_64 GNU/Linux)

The device is HP StorageWorks Ultrium 3000 SAS, cartridges are Sony LTX1500G

`ltfs -o device_list` shows connected hardware:

885 LTFS14000I LTFS starting, LTFS version 2.5.0.0 (Prelim), log level 2.
885 LTFS14058I LTFS Format Specification version 2.4.0.
885 LTFS14104I Launched by "ltfs -o device_list".
885 LTFS14105I This binary is built for Linux (x86_64).
885 LTFS14106I GCC version is 10.2.1 20210110.
885 LTFS17087I Kernel version: Linux version 5.13.19-2-pve (build@proxmox) (gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP PVE 5.13.19-4 (Mon, 29 Nov 2021 12:10:09 +0100) i386.
885 LTFS17089I Distribution: PRETTY_NAME="Debian GNU/Linux 11 (bullseye)".
885 LTFS17085I Plugin: Loading "sg" tape backend.
Tape Device list:.
Device Name = /dev/sg1 (0.0.0.0), Vendor ID = HP , Product ID = Ultrium 5-SCSI , Serial Number = HUJ011CW59, Product Name =[Ultrium 5-SCSI].

But when I try to do mkltfs, I'm getting the following error:

root@office:~# mkltfs -d /dev/sg1
LTFS15000I Starting mkltfs, LTFS version 2.5.0.0 (Prelim), log level 2.
LTFS15041I Launched by "mkltfs -d /dev/sg1".
LTFS15042I This binary is built for Linux (x86_64).
LTFS15043I GCC version is 10.2.1 20210110.
LTFS17087I Kernel version: Linux version 5.13.19-2-pve (build@proxmox) (gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP PVE 5.13.19-4 (Mon, 29 Nov 2021 12:10:09 +0100) i386.
LTFS17089I Distribution: PRETTY_NAME="Debian GNU/Linux 11 (bullseye)".
LTFS15003I Formatting device '/dev/sg1'.
LTFS15004I LTFS volume blocksize: 524288.
LTFS15005I Index partition placement policy: None.

LTFS11337I Update index-dirty flag (1) - NO_BARCODE (0x0x56531f111be0).
LTFS17085I Plugin: Loading "sg" tape backend.
LTFS30209I Opening a device through sg-ibmtape driver (/dev/sg1).
LTFS30250I Opened the SCSI tape device 0.0.0.0 (/dev/sg1).
LTFS30207I Vendor ID is HP .
LTFS30208I Product ID is Ultrium 5-SCSI .
LTFS30214I Firmware revision is Z6MW.
LTFS30215I Drive serial is HUJ011CW59.
LTFS30285I The reserved buffer size of /dev/sg1 is 524288.
LTFS30294I Setting up timeout values from RSOC.
LTFS17160I Maximum device block size is 1048576.
LTFS11330I Loading cartridge.
LTFS39805W The timeout table is not configured: SCSI OP code 0x4d. Use the default timeout.
LTFS11332I Load successful.
LTFS39805W The timeout table is not configured: SCSI OP code 0x4d. Use the default timeout.
LTFS17157I Changing the drive setting to write-anywhere mode.
LTFS15049I Checking the medium (mount).
LTFS39805W The timeout table is not configured: SCSI OP code 0x4d. Use the default timeout.
LTFS30205I LOCATE (0x92) returns -20802.
LTFS30263I LOCATE returns End-of-Data (EOD) not found (-20802) /dev/sg1.
LTFS12037E Cannot seek: backend call failed (-20802).
LTFS11006E Cannot read volume: failed to load the tape.
LTFS30205I MODESELECT (0x55) returns -20500.
LTFS30263I MODESELECT returns Invalid Field in Parameter List (-20500) /dev/sg1.
LTFS15023I Formatting failed.

Maybe you have any ideas what's the problem? The cartridges & streamer are absolutely new

Hmm, it's interesting... Is this tape really brand new?

The `mkltfs` checks the tape was already formatted or not before formatting it. Normally, the `mkltfs` checks there are two partitions format and then tries to mount the tape for checking. There are two funny points in this case.

1. The `mkltfs` didn't detect non-partitioned tape at all. Is this tape really brand new?
2. The `mkltfs` tried to seek to the end of data but the drive returned an error `End-of-Data (EOD) not found`. This is clearly drive fault if this tape really brand new. It shall find a EOD at the beginning of the tape.

You can use `--force` option to skip the LTFS format check if it is sure you can erase everything of this tape.

Yes, it's absolutely new - unpacked it some days ago.

Tried to use `--force` argument (but not sure if in the right way, no I see another error

root@office:~# mkltfs -d /dev/sg --force
LTFS15000I Starting mkltfs, LTFS version 2.5.0.0 (Prelim), log level 2.
LTFS15041I Launched by "mkltfs -d /dev/sg --force".
LTFS15042I This binary is built for Linux (x86_64).
LTFS15043I GCC version is 10.2.1 20210110.
LTFS17087I Kernel version: Linux version 5.13.19-2-pve (build@proxmox) (gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP PVE 5.13.19-4 (Mon, 29 Nov 2021 12:10:09 +0100) i386.
LTFS17089I Distribution: PRETTY_NAME="Debian GNU/Linux 11 (bullseye)".
LTFS15003I Formatting device '/dev/sg'.
LTFS15004I LTFS volume blocksize: 524288.
LTFS15005I Index partition placement policy: None.

LTFS11337I Update index-dirty flag (1) - NO_BARCODE (0x0x565238a7fc20).
LTFS17085I Plugin: Loading "sg" tape backend.
LTFS30209I Opening a device through sg-ibmtape driver (/dev/sg).
LTFS30288I Opening a tape device for drive serial /dev/sg.
LTFS12012E Cannot open device: failed backend open call.
LTFS15009E Cannot open device '/dev/sg' (-21711).
LTFS15023I Formatting failed.

I believe it is a known HBA issue. Need to recompile with `--enable-buggy-ifs`.

See #157 and URL

Recompiled. Thanks for your answer, it really helped!

root@office:/opt/ltfs# df -h | grep ltfs
ltfs:HUJ011CW59 1.4T 0 1.4T 0% /ltfs

Problems mounting tapes
All of a sudden, I'm having trouble mounting both of my tapes (which mounted before successfully). This is what I'm seeing:

Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS14000I LTFS starting, LTFS version 2.4.1.1 (10227), log level 3.
Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS14058I LTFS Format Specification version 2.4.0.
Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS14104I Launched by "ltfs -o devname=/dev/sg3 /opt/VS/vsMounts/000025L7 -o trace".
Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS14105I This binary is built for Linux (x86_64).
Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS14106I GCC version is 6.3.0 20170516.
Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS17087I Kernel version: Linux version 4.20.11 (root@debian) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Thu Feb 21 09:13:14 EST 2019 i386.
Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS17089I Distribution: PRETTY_NAME="Debian GNU/Linux 9 (stretch)".
Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS14063I Sync type is "time", Sync time is 300 sec.
Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS17085I Plugin: Loading "sg" tape backend.
Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS17085I Plugin: Loading "unified" iosched backend.
Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS14095I Set the tape device write-anywhere mode to avoid cartridge ejection.
Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS30209I Opening a device through sg-ibmtape driver (/dev/sg3).
Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS30207I Vendor ID is IBM .
Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS30208I Product ID is ULTRIUM-HH7 .
Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS30214I Firmware revision is JAY1.
Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS30215I Drive serial is 10WT074468.
Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS17160I Maximum device block size is 1048576.
Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS11330I Loading cartridge.
Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS30252I Logical block protection is disabled.
Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS11332I Load successful.
Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS17157I Changing the drive setting to write-anywhere mode.
Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS11005I Mounting the volume.
Sep 9 07:34:15 alice2 ltfs[25588]: 63f4 LTFS30252I Logical block protection is disabled.
Sep 9 07:34:21 alice2 ltfs[25588]: 63f4 LTFS30216W Length mismatch is detected. (Act = 4096, resid = 0, resid_sense = -520192).
Sep 9 07:34:21 alice2 ltfs[25588]: 63f4 LTFS30216W Length mismatch is detected. (Act = 4096, resid = 0, resid_sense = -520192).
Sep 9 07:34:21 alice2 ltfs[25588]: 63f4 LTFS12049E Cannot read: backend call failed (-21716).
Sep 9 07:34:21 alice2 ltfs[25588]: 63f4 LTFS11174E Cannot read ANSI label: read failed (-21716).
Sep 9 07:34:21 alice2 ltfs[25588]: 63f4 LTFS11171E Failed to read label (-21716) from partition 1.
Sep 9 07:34:21 alice2 ltfs[25588]: 63f4 LTFS11009E Cannot read volume: failed to read partition labels.
Sep 9 07:34:21 alice2 ltfs[25588]: 63f4 LTFS14013E Cannot mount the volume.
Sep 9 07:34:21 alice2 ltfs[25588]: 63f4 LTFS30252I Logical block protection is disabled.

It doesn't look like `--enable-buggy-ifs` would help in this case as it seems to be an overrun.

HBA is:

06:08.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068 PCI-X Fusion-MPT SAS (rev 01)

I don't think `--enable-buggy-ifs` is effective in this binary. Because `LTFS30216W` is logged only when `SUPPORT_BUGGY_IFS` is not defined.

Sep 9 07:34:21 alice2 ltfs[25588]: 63f4 LTFS30216W Length mismatch is detected. (Act = 4096, resid = 0, resid_sense = -520192).

 URL

Could you confirm `-DSUPPORT_BUGGY_IFS` is added in the build process of LTFS?

`SUPPORT_BUGGY_IFS` is NOT enabled in this case. I mentioned `SUPPORT_BUGGY_LFS` because I don't think it will help me in this case, because `diff_len < 0` so it would just fail anyway with `-EDEV_OVERRUN` instead of `-EDEV_LENGTH_MISMATCH`.

Thank you for your clarification. I got your point.

Could you put the log with `-o verbose=606`? LTFS may log more detail.

It looks there is no chance to support this HBA. LTFS tried to read rec #0 (VOL1 = 80 bytes) but there is no chance to detect the read record is 80-byte long from returned information...

Sep 10 06:37:38 alice2 ltfs[21640]: 5488 LTFS30201D CDB check condition: sense = 000000, No Additional Sense Information.
Sep 10 06:37:38 alice2 ltfs[21640]: 5488 LTFS30204D READ (0x08) expected error -20000.
Sep 10 06:37:38 alice2 ltfs[21640]: 5488 LTFS30216W Length mismatch is detected. (Act = 4096, resid = 0, resid_sense = -520192).

I strongly recommend to use newer and famous HBA.

But I saw similar issues in the past. I cannot grantee anything but you can try on your risk. (Again I cannot guarantee even if you crash this HBA on the methods below...)

1. Some RAID supported adapters (I don't remember the parts number) make a funny behhavior against tape device when RAID feature is on. You can try this HBA with RAID feature off
2. I think this HBA is used on VM as a virtual HBA to bridge physical HBA on the machine. If so, you can to use iSCSI instead
3. You might have some `TAPE SUPPORT` switch on the configuration utility of the HBA if you are lucky
4. You may have latest firmware of the HBA. The latest firmware may help you if you are lucky

Yes, we've heard that RAID supported adapters do not work well with tape drives. We have another HBA on order.

Do you have a list of recommended HBAs that work well with LTFS?

I'm sorry, I have realized my previous analysis is wrong... The HBA may be not bad...

On partition 0, LTFS can receive residual length like

Sep 10 06:37:32 alice2 ltfs[21640]: 5488 LTFS30398D Backend readpos: (0, 0) FM = 0 10WT074468.
Sep 10 06:37:32 alice2 ltfs[21640]: 5488 LTFS39801D SCSI timeout (op_code 0x08, timeout = 2340).
Sep 10 06:37:33 alice2 ltfs[21640]: 5488 LTFS30201D CDB check condition: sense = 000000, No Additional Sense Information.
Sep 10 06:37:33 alice2 ltfs[21640]: 5488 LTFS30204D READ (0x08) expected error -20000.
Sep 10 06:37:33 alice2 ltfs[21640]: 5488 LTFS30218D Read block: underrun in illegal length. residual = 4016, actual = 80.
Sep 10 06:37:33 alice2 ltfs[21640]: 5488 LTFS30395D Backend read: 4096 bytes 10WT074468.

But LTFS detects overrun condition on partition 1.

Sep 10 06:37:38 alice2 ltfs[21640]: 5488 LTFS30398D Backend readpos: (1, 0) FM = 0 10WT074468.
Sep 10 06:37:38 alice2 ltfs[21640]: 5488 LTFS39801D SCSI timeout (op_code 0x08, timeout = 2340).
Sep 10 06:37:38 alice2 ltfs[21640]: 5488 LTFS30201D CDB check condition: sense = 000000, No Additional Sense Information.
Sep 10 06:37:38 alice2 ltfs[21640]: 5488 LTFS30204D READ (0x08) expected error -20000.
Sep 10 06:37:38 alice2 ltfs[21640]: 5488 LTFS30216W Length mismatch is detected. (Act = 4096, resid = 0, resid_sense = -520192).

From the residual information, actual read is 4096 and remaining length is 520192. So teh record length on the tape shall 4096 + 520192 = 524288 (512 * 1024).

I believe LTFS wrote the data at the beginning of partiton1 while it's writing a file. The only possibility come up to my mind is someone opened /dev/st? while LTFS is running. It may rewind the tape in the middle of LTFS operations.

LTFS uses a data protection mechanism of the drive when it can be used. But it may not be enabled in this case.

Oh. That actually may be a possibility. The system I'm working with will periodically open the tape device to check the serial number, etc. Originally it was using /dev/sg?, but that failed when LTFS had mounted the tape. So, I switched it the process to use /dev/st?. I guess I need to avoid opening /dev/st? at all while LTFS has /dev/sg? mounted?

This seems to be working fine after I reformatted and switched to using /dev/nst* for status calls. Thanks for the help!


Question: Replace `Foreign.Marshal.Error.void` with a re-export of `Data.Functor.void`?

OK, let's vote on this.

Dear CLC members, the proposal is to extend Impact Assessments section of `PROPOSALS.md` with a paragraph

@angerman @hasufell @tomjaguarpaw @parsonsmatt @velveteer @mixphix

----

+1 from me, see my comment above.

Replace `Foreign.Marshal.Error.void` with a re-export of `Data.Functor.void`
These two functions have identical behavior and names, but differing types. (This can cause annoying and pointless "ambiguous occurrence" errors when both are in scope.) `Data.Functor.void` is more general than `Foreign.Marshal.Error.void`, but the proposed change is nevertheless a breaking one since the more general type of `Data.Functor.void` can cause type inference to fail in some cases.

But `Foreign.Marshal.Error.void` has been deprecated since `base-4.6.0.0`, which shipped with ghc-7.6.1 and was released in September 2012, more than a decade ago. Potentially-affected users have had plenty of time to migrate.

Side note: `Foreign.Marshal.Error.void` is specified in the Haskell2010 report; see this chapter. Otherwise I might propose to just delete this function instead of generalizing it.

Given that the function is deprecated for a decade, I don’t see a reason not to delete it. We are way far away from Haskell Report to bother about it.

@tomjaguarpaw @mixphix @hasufell @angerman @parsonsmatt @velveteer any more opinions about `Foreign.Marshal.Error.void`?

I would like a base that conforms to the spec or an update to the spec.

Do we know why the deprecation was introduced?

I don't see base in the 7.6 tree URL

I don't have a strong opinion between the three options (no change, replace with general version, remove it).

It was deprecated by @simonmar in URL Apr 2012, but there is no explanation or discussion attached.

Given the deprecation message I guess the reason was that the more general version of `void` should be preferred!

{-# DEPRECATED void "use Control.Monad.void instead" #-}

@parsonsmatt @angerman @velveteer any more opinion on the preferred course of actions here?

Another point to consider: A fair number of packages have `import Foreign hiding ( void )` which will trigger a `-Wdodgy-imports` warning if `void` is completely removed from `Foreign.Marshal.Error`. That's not a big deal: there are several acceptable ways of dealing with this warning, including silencing it. But it does probably create busy-work for the relevant maintainers, which could be avoided by replacing `Foreign.Marshal.Error.void` with a re-export of `Data.Functor.void`.

But I won't sleep any less soundly if the committee still prefers to delete the function instead.

@clyring we don't consider warnings breaking changes: URL

Werror users get what they asked for.

I think we all agree that `Foreign.Marshal.Error` is not a right place for `void :: Functor f => f a -> f ()`, it's just that CLC members may have different appetite when it comes to breakage.

As noted in the proposal, replacing `void :: IO a -> IO ()` with `void :: Functor f => f a -> f ()` is also a breaking change, because it can potentially make type checking ambiguous. So it would require an impact assessment, same as just removing it. So I guess it's a question which impact assessment (and patches) @clyring is motivated enough to perform.

If we go for re-export, let's *deprecate* it, so that we do not close the door to the eventual removal of the function.

@clyring unless there is some progress by the end of August, I'll have to close the proposal as abandoned.

Closing as abandoned, feel free to reopen when there are resources to continue.

Regarding "-Werror" and how the proposals are examined by the committee
Hello committee,

In light of recent proposals that were discussed with deprecation and warning mechanisms at their core, I see a strange phenomenon of pleading for users of `-Werror`, that is to say the flag that turns every warning, no matter how benign, and including `-Wcompat`, into fatal errors.

This is quite surprising because users of `-Werror` voluntarily checked out of the ability to be programmatically warned ahead of time for breaking changes that would happen in a couple of major releases. By not being selective on which warning they want to turn into errors, they prefer to have things break early, compromising neither on the "break", nor on the "early".

Hence from my point of view, it is quite peculiar to see arguments opposed to future breaking changes with a progressive deprecation phase, in order to protect the users who so dearly wish things to break early.

I would like to ask the committee to solve the matter of `-Werror` once and for all, preferring solutions like warning groups, that allow granularity, instead of never ever emitting any kind of warning at all.

This shouldn't even be a discussion. If you enabled -Werror you are asking for early fatal breakage. And that's what you get. We should not entertain the idea that -Werror need to be considered when deprecating. The whole point is to warn people for upcoming changes. If you run with -Werror you get the warning as fatal error early. Not a bit later when it fatally breaks. Deprecations allow you to also get some more context as to why. And you can often specifically opt out of a specific warning at the module level if you so need to.

I think what sparked this thread is that these types of discussions are constantly coming up. So the question is if we as a CLC should encode common singular principles we all agree on in a document, so that contributors know what they're getting into and we can just link to the document whenever it comes up again.

Such a document wouldn't really be set in stone and could as well be discarded by a future CLC.

But I believe it makes things a bit easier.

This is far less ambitious than coming up with a "stability policy". I see this really about avoiding repetitive discussions.

I agree, and mind you I'm addicted to `-Werror -Wall -Wcompat` stuff.

@mixphix Don't feel targeted if you're not guilty of this. This sort of principle also applies to submitters and third-party reviewers on the proposals.

GHC's new stability principles explicitly say that they will not keep warnings stable: URL

(Obviously the CLC can do something different to GHC, but it's a reference point)

@Kleidukos what kind of a format resolution besides personal statements from CLC members are you looking for if any?

@Bodigrim A note in Impact Assessments would be the end goal, so that the opinion of the CLC doesn't get lost in this ticket when it is closed.

@Kleidukos would you like to suggest a specific wording? How about the following?

"Note that additional or new warnings and deprecations are not classified as breaking changes. We assume that users who enable `-Werror` make a conscious and informed choice to break their builds as early and as fatal as possible."

Such wording still allows CLC members to have individual opinions whether a given warning / deprecation is worth the trouble. It's not like anyone can incur as many warnings as they like, but they do not count towards breakage and do not require a proposer to write patches to fix them.

Thanks all, that's enough votes to approve. I'll implement the change in a moment.


Question: [Bug Report][3.0.0-beta.10] `v-select`'s label get active always?

This has since been resolved with the property **cache-items**.

 URL

Closing this as resolved.

If you have any questions, please reach out to us in our Discord community.

[Bug Report][3.0.0-beta.10] `v-select`'s label get active always
### Environment
**Vuetify Version:** 3.0.0-beta.10
**Vue Version:** 3.2.38
**Browsers:** Chrome 105.0.0.0
**OS:** Windows 10

### Steps to reproduce
Try to use blank string `v-model` value and you see the label get an active state

 data: () => ({
 items: ['Foo', 'Bar', 'Fizz', 'Buzz'],
 standardSelect: '',
 outlinedSelect:'',
 soloVariant:'',
 plainVariant:'',
 underlinedVariant:'',
 }),

### Expected Behavior
v-select does not get an active state

### Actual Behavior
Refer to code pen for details

### Reproduction Link
 URL

Hello @KaelWD,

In Vuetify 2, Select does not behave the same when I use a blank string as model value: URL

Sorry, power outage deleted my response.

v3 keeps items defined in the model (#4000), so this is more like URL
An initial value of `null` has the behaviour you want.

Thanks for the response.

Now, we are using null for the initial value.

[Bug Report] Selected options are removed when options are updated even when options are available in model property
### Versions and Environment
**Vuetify:** 1.0.16
**Vue:** 2.5.11
**Browsers:** Chrome 66.0.3359.139
**OS:** Windows 7

### Steps to reproduce
Click on update button.
Then see in model there is but selection is removed from v-select

### Expected Behavior
Option should not removed from selection

### Actual Behavior
It is removed from selection

### Reproduction Link
 URL

That behaviour is intentional, although it should be removed from the model too iirc.

Hi @KaelWD, I want behavior like, if i remove from list after selecting it should be displayed as selected.
Is that possible?

If you use `cache-items` then yes, although it will still be visible in the menu. I don't really know what your use-case is for this though.

@KaelWD thanks for your answer, I can use cache-items but if it would be good if removed item is not visible in list.

And if you want reference of this use-case, you can check libraries like vue-multiselect or element-ui's select component.

I don't think that's good behavior. If the item is removed from the list but still selected then there will be no way to unselect it. The `el-select` seems similar to our ` ` however, which does appear to have the behaviour you want.

@KaelWD But if i make v-select autocomplete then there is problem.
It will allow user to create tag.

Hi @KaelWD , can you check changes I made related to this issue.
And I am new to contributing, if there is anything I can improve you can tell me

You cannot have a selection that is not present in the available options. The fact that it leaves the model is completely fine as you can provide whatever value you want to the input. I see that you provided an example of another framework working as you want, but I'd argue to say that it is invalid and not what you would expect from a regular select, so it will not be here.

Hi @johnleider, I also agree with you. But in my use-case I want this behaviour, ok let me tell you how I am using v-select.
I have four v-select.
1.) Destinations
2.) Sailing Dates
3.) Sailing Duration
4.) Departure Ports

And all four v-select's options are dependent on each other, means if I select destination it will update all other three v-select's options.

So, if user selected 3 destination then it will update all other three and after that if user selects from available Sailing Dates it will also update destinations then user's selection will disappear from v-select.

I don't know about you, but if I am the user and my selection is removed automatically without touching it, I will be pissed.

This could be solved by for example adding the already selected option to the updated values and notifying the user that it is no longer valid, for example displaying it as disabled or with red text.

@nekosaur yup I can update the list, but then it will change the position of selected value and for displaying it as disabled is not appropriate in my case because I want the user to have with option to deselect it even if it is not in the list because I am maintain the another array for that.

What do you say?

I can see the argument for both of these, and the current behaviour is technically buggy too because it removes the value from the input but doesn't update the model. I don't like adding yet another prop to the component though, so we have to decide if it should instead be the default behaviour to show the model even if it's not in items.

I would say this is out of the hands of the component. If you are mutating the items to dynamically remove items, you should dynamically update the model as well.

We've decided to consider this after someone on discord posted a similar problem: URL

Is there a workaround, while this issue gets resolved?
I am using `v-autocomplete` to search for a list of names asynchronously using an API call. I show 5 names initially. When user searches for a name, API call is made to fetch search results. I am using `cache-items` prop.
Now, my requirement is as follows:
When the `v-autocomplete` loads, I want to provide it with some pre-selected names. The problem I am running into is that since some of the pre-selected names are not available in the initial list of names, they never show up in the selection.
So, for example, There are 20 names on the server(`name1`,`name2`,.....`name20`) and the initial list only has 5 names(`name1` to `name5`). Now, if I want `name7` to be already selected, it is not possible right now because it is not present in the list.

The workaround I found out is to manually add set model's value using searchInput's setter, triggering a server query, here is a working codepen, I usually use Vuex and lodash to throttle server requests
 URL

I needed to do an autocomplete with multiple selection and server side rendered list (the user able to select one or more names, which have too many options), `cache-items` would not be an option since they wanted multiple field filtering (the text can match the name or the login name), so I used no-filter prop to give this responsibility solely to the server.
The workaround I made for this case is to use `prepend-item` slot to show the selected items inside my own value variable. I show them as a list with a checkbox icon in the tile action to indicate that it is selected and a divider for aesthetics.
I tried to use `selection` prop to show the number of selected items only at the first item, but I ran into this problem, which was making the text disappear when the user tried to filter for another result, so I am using `prepend-inner` slot for it, with a span wrapped in a slide-x transition for smoothness.
I know this is an edgy use case, but still a use case for what the component proposes

@KaelWD Does this issue have an open PR? The label `has PR` was attached a long time ago and since then nothing has happened.

@kanteankit It had open PR but library author closed PR with comment **Unfortunately this is not functionality that we are looking to implement at this time.**

PR Link: URL

@johnleider Can we re-open it and see if this can get fixed?

@akki-jat That is the answer for most PR, I do not understand why bug fixing is not the functionality you intend to implement, would you prefer something with bugs? it is?

@akki-jat That is the answer for most PR, I do not understand why bug fixing is not the functionality you intend to implement. Prefer components with bugs? it is?

Is there an update on this? It seems there is a fair amount of traffic linked to this issue and should be pushed up the stack.

With cache-items, the item still shows up when unselected which is unwanted in a server side rendered options scenario. One way I found out was to use computed property: URL

Probably it could be helpful for someone, I tried workaround suggested above ( URL but i need to use server side search by many attributes, and if i simply add `no-filter` prop then selected options would still be displayed in list, regardless of whether they meet search condition or not.
So i added `filter` prop with following value:

 filter(item) {
 return this.searchResults.some((itemFromServer) => itemFromServer.id === item.id)
 },

Here i just check if item exist in array received from the server. And if it exists, then it will be displayed in the list. If it not, then it won't be displayed, but it still will be presented in VAutocomplete items, thus selected items remain visible.


Question: importing electron in a WebWorker doesn't work?

This isn't a bug - using IPC requires a render frame, which a worker doesn't and can't have.

importing electron in a WebWorker doesn't work
Doing `import { ipcRenderer} from 'electron'` (or any other renderer electron module) crashes the app with `reason: "crashed"` and `exitCode: 11`.

## Details

- I'm trying to migrate from Webpack and the same code works there.
- `nodeIntegrationInWorker` is set to true.
- Exit code 11 usually means Segmentation fault.
- One thing that is being logged in the Terminal when the app crashes:

 [20890:0831/172750.464535:ERROR:shared_image_manager.cc(267)] SharedImageManager::ProduceOverlay: Trying to Produce a Overlay representation from a non-existent mailbox.
 [20890:0831/172750.464559:ERROR:skia_output_device_buffer_queue.cc(354)] Invalid mailbox.
 [20890:0831/172750.464564:ERROR:shared_image_manager.cc(267)] SharedImageManager::ProduceOverlay: Trying to Produce a Overlay representation from a non-existent mailbox.
 [20890:0831/172750.464569:ERROR:skia_output_device_buffer_queue.cc(354)] Invalid mailbox.
 [20890:0831/172750.464572:ERROR:shared_image_manager.cc(267)] SharedImageManager::ProduceOverlay: Trying to Produce a Overlay representation from a non-existent mailbox.
 [20890:0831/172750.464578:ERROR:skia_output_device_buffer_queue.cc(354)] Invalid mailbox.
 [20890:0831/172750.464580:ERROR:shared_image_manager.cc(267)] SharedImageManager::ProduceOverlay: Trying to Produce a Overlay representation from a non-existent mailbox.
 [20890:0831/172750.464584:ERROR:skia_output_device_buffer_queue.cc(354)] Invalid mailbox.
 [20890:0831/172750.464601:ERROR:shared_image_manager.cc(267)] SharedImageManager::ProduceOverlay: Trying to Produce a Overlay representation from a non-existent mailbox.
 [20890:0831/172750.464606:ERROR:skia_output_device_buffer_queue.cc(354)] Invalid mailbox.
 [20890:0831/172750.464609:ERROR:shared_image_manager.cc(267)] SharedImageManager::ProduceOverlay: Trying to Produce a Overlay representation from a non-existent mailbox.
 [20890:0831/172750.464612:ERROR:skia_output_device_buffer_queue.cc(354)] Invalid mailbox.

- Another thing:

 Error sending from webFrameMain: Error: Render frame was disposed before WebFrameMain could be accessed
 at n._sendInternal (node:electron/js2c/browser_init:165:629)
 at b._sendInternal (node:electron/js2c/browser_init:161:2573)
 at node:electron/js2c/browser_init:193:729
 at new Promise ( )
 at Object.invokeInWebContents (node:electron/js2c/browser_init:193:477)
 at b.executeJavaScript (node:electron/js2c/browser_init:161:3267)
 at process.processTicksAndRejections (node:internal/process/task_queues:96:5)

I think that's the reason for the crash: URL

Closing this issue. Sorry for incorrectly reporting it here.

Was wrong about it. Upgrading Electron to the latest doesn't fix the problem. The problem is somewhere else.

Yes. I will start working on building a reproducible demo.

Did you try to import and call an electron module in a WebWorker (loaded with `type: "module"`)? Does it work for you?

`type: "module"` will be supported in `v0.9.3`, coming soon. 🚚

Great! So, for now, there is no need for me to create a reproducible demo, right?

<img width="1340" alt="image" src=" URL
There's something wrong with building esm support, I'm trying to Debug Vite and it's confusing.
Or I'll use Rollup to get around this.
Sorry for the wait.

A little context (it might be useful for you):
- I don't get any error from Vite when using `type: "module"` when creating a new WebWorker.
- `import something from 'module'` doesn't work if I don't set the `type: "module"`.

I also may use WebWorker without `type: "module"` but I'm not sure how should I import stuff. Maybe it's not possible?

`type: "module"` doesn't work with Electron, probably because Electron doesn't support ESM well.
I built the ESM version of the plugin, but Electron doesn't work when `type: "module"` is enabled.

Support `type: "module"` branch 👉 vite-plugin-electron/tree/type-module

Run setup

bash
cd playground/usecase-in-main

npm run dev

Errors

log
App threw an error during load
Error [ERR_REQUIRE_ESM]: require() of ES Module /Users/atom/Desktop/github/vite-plugin-electron/playground/usecase-in-main/dist/electron/main/index.js from /Users/atom/Desktop/github/vite-plugin-electron/node_modules/.pnpm/electron@19.0.8/node_modules/electron/dist/Electron.app/Contents/Resources/default_app.asar/main.js not supported.
Instead change the require of index.js in /Users/atom/Desktop/github/vite-plugin-electron/node_modules/.pnpm/electron@19.0.8/node_modules/electron/dist/Electron.app/Contents/Resources/default_app.asar/main.js to a dynamic import() which is available in all CommonJS modules.
 at c._load (node:electron/js2c/asar_bundle:5:13343)
 at loadApplicationPackage (/Users/atom/Desktop/github/vite-plugin-electron/node_modules/.pnpm/electron@19.0.8/node_modules/electron/dist/Electron.app/Contents/Resources/default_app.asar/main.js:110:16)
 at Object. (/Users/atom/Desktop/github/vite-plugin-electron/node_modules/.pnpm/electron@19.0.8/node_modules/electron/dist/Electron.app/Contents/Resources/default_app.asar/main.js:222:9)
 at c._load (node:electron/js2c/asar_bundle:5:13343)
 at Object. (node:electron/js2c/browser_init:185:3104)
 at ./lib/browser/init.ts (node:electron/js2c/browser_init:185:3308)
 at __webpack_require__ (node:electron/js2c/browser_init:1:128)
 at node:electron/js2c/browser_init:1:1200
 at node:electron/js2c/browser_init:1:1267
 at c._load (node:electron/js2c/asar_bundle:5:13343)

I'm creating the WebWorker from the renderer process. Is this relevant?

I'm in the process of swapping from webpack to vite, and one of the issues I have atm is the production build is crashing when trying to use nodejs modules, but works fine in development.

e.g.

`index.ts`:

import TestWorker from "@/workers/test-worker?worker";
const testWorker = new TestWorker();

`workers/test-worker.ts`:

import * as path from "path";
console.log(path.parse(__dirname));

I have `nodeIntegrationInWorker: true`, and as I said it works fine in development, but in the production build it doesn't recognise the path module and the built worker file looks a little sketchy:

image

Is this the right issue to report this? Am curious if the work you're doing will fix this or if my issue is unrelated.

This project is just for my personal interest, I have not tested many cases, such as `web worder`.
By the way, Vite behaves very differently during development and build, so I run into really tricky issues a lot of the time.

Done. Here is the repo: URL

The important part is in `renderer/main.ts`:

ts
document.body.addEventListener('click', () => {
 new Worker(new URL('./worker.ts', import.meta.url), {
 type: 'module'
 })
})

Clicking on the "hello" text will run the code and the `BrowserWindow` will crash. You can open DevTools before you click the "hello" text so you can see DevTools shows a message as well.

@astoilkov 👋
Eventually, I found that using `ipcRenderer` in a Web Worker would cause the Electron-Renderer to crash. This is confusing!
 URL
I submitted a PR to try to bypass access to ipcRenderer.

Great, thanks! Are you going to implement a fix in electron-vite-renderer?

This problem may come from Electron itself, what we can do is to hide `ipcRenderer` when using electron module in Web Worker. Not sure if this is the right thing to do or if we need to state this in the README.md. 🤔

I think you can safely hide `ipcRenderer` in Web Worker because it seems, as I learned just now, that you shouldn't access it and the behavior is expected because there isn't a `webFrame` inside of workers — URL

Another idea: You can throw an error if someone tries to access an ipcRenderer property (using a Proxy) and explain the issue. This will be very helpful to other users.

[Bug]: BrowserWindow crashes after web worker calls ipcRenderer.invoke
### Preflight Checklist

- [X] I have read the Contributing Guidelines for this project.
- [X] I agree to follow the Code of Conduct that this project adheres to.
- [X] I have searched the issue tracker for a bug report that matches the one I want to file, without success.

### Electron Version

17.4.10

### What operating system are you using?

Windows

### Operating System Version

windows 10 21H1

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

Can call ipcRenderer.invoke or ipcRenderer.send normally in the web worker

### Actual Behavior

BrowserWindow crashes after web worker calls ipcRenderer.invoke or ipcRenderer.send

### Testcase Gist URL

 URL

### Additional Information

_No response_

Maybe not a bug but it took me days to discover this problem and understand why our Web Worker is crashing. Maybe you can just handle the error and throw a user friendly error.


Question: Component level note content needs to allow text formatting?

Example of text formatting not rendering in : URL

code snippet:
`

 "Singing for her supper," The Hill , pp.
 30-31 `

I will add an example of text formatting not rendering in component level notes shortly.

Component level note content needs to allow text formatting
## Summary
Right now all note types allow text formatting for its content with a few exceptions:
- `dimensions`
- `physfacet`
- `acqinfo`

The following note types aren't displaying at all when the content has text formatting
- `physdesc`
- `index`

`physdesc` may be the place to start because `dimensions` and `physfacet` are EAG tags nested within `physdesc`.

This issue may overlap with AR-136 In Progress which calls for text formatting in component `unittitle`

Please see the attached spreadsheet for data on whether or not a note type displays and/or allows text formatting.
component_notes_text.xlsx

## Acceptance Criteria
- [ ] Text formatting is allowed and displays on all note types that are listed in the above spreadsheet

## Testing Instructions
- Use the G334 – 54 slides component on staging
- Ensure there is bold or underline formatting for the following:
 - Acquisition information
 - Physical description
 - Physical facet
 - Dimensions
 - Indexes

 Text formatting

Image

From Bri:

Components are the items (series, subseries, etc) within a finding aid. Some people call it an inventory. In EAD XML terms, components are within . Ticket #102 dealt with component title text formatting, but #153 addresses notes within . I don't think there are any examples in the Notch8 staying site, but here is an example from another EAD.

 General

(Enclosing The PLAC [newsletter of the Patent Law Association of Chicago], Vol. 6, No. 3, October 1979, pp. 1-4;
 An Evening at the Washington Award,
 Midwest Engineer
; Letter from John J. Chrystal of the Patent Law Association of Chicago to Joe Allen of October 19, 1979; and Draft bill to establish Patent and Trademark Office as a separate entity)

@brijmcla I am having a hard time finding an example of text formatting in any of the tags listed in this ticket. Do you have an example of a `physdesc` tag, ideally with a nested `dimensions` and `physfacet` that has text formatting?

There isn't an existing example in the Notch8 staging site. Here is a code example that I edited from the component G334 – 54 slides from the Hattin finding aid.

 G334 – 54 slides
 1

# QA RESULTS: :warning: PENDING

tested on STAGING

## Acceptance Criteria
- [ ] Text formatting is allowed and displays on all note types that are listed in the above spreadsheet

## Testing Instructions
- Use the G334 – 54 slides component on staging
- Ensure there is bold or underline formatting for the following:
 - Acquisition information
 - Physical description
 - Physical facet
 - Dimensions
 - Indexes

 Text formatting

Image

@brijmcla we are finishing up our last ticket for the sprint. This is ready for your review!

Improving text formatting at item level titles
# ⚠ REQUIRES REINDEXING ⚠

## Summary
Text formatting at item level title not coming through

**Current**

**Expected archives.iu.edu**

## Acceptance Criteria
- [ ] As a user EAD formatting attributes are consistent across all item level titles

Bri to share an example of what this should look like. Currently the code exists to format EAD information, it's just not coming in

Scratch adding an example in notes. This ticket is scoped for .

Bri confirmed it looks like the issues is with the attribute `render="italic"` as opposed to something like a tag for rendering italics

cc @kirkkwang I've triggered a deploy to prod. Could you reindex staging when it's ready and move to QA once that's done?