justinbowes

Hello Unraid team, Please let me begin by expressing my appreciation for your product and your business practices. I have invested a lot of time into my home serving and automation environment on top of Unraid, due to the level of support, community engagement, and core product reliability you offer. The product supports all of the home server characteristics so well -- diverse hardware, diverse storage, diverse networking, diverse deployment of hosted applications. That said, we need to discuss Connect. It's a different model with different expectations. I am sympathetic, and I know it's "beta" software, but I believe you're missing the mark right now. As an experienced developer, I know that things might look like bugs to me and be working as intended for you. I'm going to flag where the system did something I didn't expect, like this: ⚠️ Today's IssueResolving an Unraid Connect plugin auth errorToday, my Unraid instance had a red shield icon in the corner, saying Invalid Credentials. 1. Unraid UI shows "invalid credentials" ⚠️.When an external service with admin capability to my home server complains that my credentials are invalid, I have to investigate this as an auth issue, which could in turn be a security issue. (Also, you picked a red shield icon for the notification, reinforcing the idea of security/protection.) There is no indication of a problem on your status page, and no announcement of a system issue, so I should treat this as a problem with my server and integration. There's nothing like an unraid-connect-plugin.log in the log viewer ⚠️. Doing some web searching, I see some indication that you use GraphQL, and I see that there's a graphql-api.log so that's promising. Sure enough: [11:34:16.689] [31mERROR[39m: [36mNetwork Error[39m [90m{"apiVersion":"4.15.1+6edd3a3","logger":"api","context":"MothershipGraphqlClientService"}[39m err: { "type": "Error", "message": "\"error\" message expects the 'payload' property to be an array of GraphQL errors, but got \"API Key Invalid with error No user found\"", "stack": Error: "error" message expects the 'payload' property to be an array of GraphQL errors, but got "API Key Invalid with error No user found" at validateMessage (file:///usr/local/unraid-api/node_modules/graphql-ws/dist/common-CGW11Fyb.js:169:15) at parseMessage (file:///usr/local/unraid-api/node_modules/graphql-ws/dist/common-CGW11Fyb.js:198:10) at socket2.onmessage (file:///usr/local/unraid-api/node_modules/graphql-ws/dist/client.js:202:29) at callListener (/usr/local/unraid-api/node_modules/ws/lib/event-target.js:290:14) at WebsocketWithMothershipHeaders.onMessage (/usr/local/unraid-api/node_modules/ws/lib/event-target.js:209:9) at WebsocketWithMothershipHeaders.emit (node:events:518:28) at WebsocketWithMothershipHeaders.emit (node:domain:489:12) at Receiver.receiverOnMessage (/usr/local/unraid-api/node_modules/ws/lib/websocket.js:1220:20) at Receiver.emit (node:events:518:28) at Receiver.emit (node:domain:489:12) } [11:34:16.69I can see the API key in Settings/ManagementAccess, but I can't see any way to rotate the key ⚠️. Does it automatically rotate? Need to remember to look into that. Going back to the web, I see that this issue is being discussed on socials now, with a suggested solution being "update the plugin" or "restart the API service." 2. Restarting the API plugin clears the error, but I'm no longer integrated with Connect ⚠️.The Connect menu in the corner says I should now "Sign in." I guess I am not able to restore the integration and I need to create new credentials. 3. Since the plugin manages the API integration, the only way to reconfigure the integration is to "Sign in with Unraid.net account".Signing in to the Connect cloud application to restore the integration makes sense -- you would want both ends to be authorized, with my access to the server implying local authorization. Okay, let's proceed. 4. Signing in requires re-registering my server ⚠️, which fails ⚠️.The sign-in flow is actually a server registration flow. The registration flow fails with an error popup but no details ⚠️. Inspecting the payload reveals this response, which the UI does not display ⚠️. Not sure how most users would be expected to follow the instructions. {"message":"Request failed with status code 403","data":"ERROR: Something went wrong while processing your request. \n\nPlease contact support at https://unraid.net/support with this error code: '39bc9cae-6d8e-4880-8fac-51b2a5798df4'.\nInclude what you were trying to do when you received this error and we will get back to you as soon as possible."}But gosh, I hate to trouble support if there are more things I can look into on my own. Perhaps this is because the Unraid Connect cloud application already has my server registered. 5. Removing my server fails on the first attempt ⚠️, and when it succeeds, it seems to break the server dashboard ⚠️.I can sign into connect.unraid.net with my credentials. My server shows as offline. I remove it. I retry the registration flow, which fails again. I return to the dashboard and my server is still there. I remove it again. I reload the dashboard. Now the server panel just displays an endless "Loading" indicator. Inspecting network activity, I can see that there is an active WebSocket connection to mothership.unraid.net and no errors in the console. I remember this endless loading indicator behavior from my first attempt to register with Connect, so I assume this is just a minor UI issue and continue on. 6. Reactivating works after having deleted my server, so I successfully rotated my API key. However, I now need to restore some management settings⚠️.The registration flow works after removing my server, and I am returned to the Management page on my own server. I see that Tailscale, SSL certificate configuration, and all my other (locally-stored?) management settings are still correct. However, the Flash Backup setting needs to be reactivated. Why does that one setting require re-enrollment? (I take note of the Unraid.net SSO configuration also -- not sure if I'd need to restore access restrictions here.) SummaryIt's clear that this experience didn't meet my expectations. I had an auth issue (which is scary), I never got enough information to understand why it happened, and restoring the integration was surprising (and maybe slightly broken) at several points. Underlying IssueI see some common threads here that I think I understand, and I'd like to be sure you're aware of them. 1. Service offerings have different requirements and user expectations than product offerings.The market for your product is users with a particular skill set. You expose to us a lot of power and a lot of ability to help ourselves. It is reasonable to expect us to use the tools and skills to solve whatever problems we are having, as individuals, and as a community since you maintain great community tools as well. When you attach a service offering to that, many things are different. We have limited observability when issues arise. We cannot/should not fork the Unraid Connector plugin, for example, to have it produce better error messages. If you don't provide any details, we don't know whether an error message means "your plugin needs an update," "we're down for maintenance for 15 minutes," or "we're in the middle of a major meltdown right now; please leave us alone." You are managing expectations around Connect by calling it a "beta" product. I don't want to dig into the loaded expectations around quality at various early access states. I would just suggest that the tradeoffs for a product at the current maturity level of Connect should probably emphasize: exposing more diagnostic data, over creating streamlined UI that hides it explaining what actions accomplish for the user (register my server with Unraid Connect) versus auth UI (status lights, etc) that will probably only be seen by users in two states: "not yet registered" and "working+all good". allowing manual operations (API key rotation) rather than automating them without sufficient recovery procedures, documentation or guardrails 2. Unraid as a product sets a particularly high bar for the functioning of Unraid as a service.Your wonderful product runs our variously secured internal services, and in many cases the security strategy for those services is "don't expose them to the internet." But with its management UI and APIs, Unraid (the product) has the keys to the whole kingdom, and if we expose that to external access, then the integration needs to be especially trusted and secure. If we can't trust Unraid Connect, then we can't use it with Unraid. Simple enough. To be fair, the issues today all failed in the right direction -- erring on the side of Connect not working. But the error reporting was inadequate at every step, and I'd still dearly like to know what happened with my last API key. 3. The community-supported model doesn't work for a cloud application. You need all the regular SaaS user management features and efforts.The typical toolkit involves: A way to push system status updates to users, to notify them of degraded service. For Unraid, if Connect and the plugin were both able to pull a toast message from the status API, that might be sufficient. A page that you actually maintain, published maintenance windows, and an incident report with RCCA for every incident. (Bad: seeing 16 hours of downtime for "Unraid Keys" without an explanation of what "Unraid Keys" service is or any explanation of why it was down. Worse: having an issue that other users are experiencing and not seeing it on the status board.) Push integration with all your community channels to notify them when you have an incident. Thanks and a pleaI appreciate Unraid and recommend it to others on the regular. I am happy to offer my opinion about what would make a better product, and I'm thrilled that you're building a new platform while generally not compromising what makes your existing product great. However, I think Connect is currently undermining what you've built. It looks more robust than it is (possibly due to development priorities in the project). In terms of operations and process, it looks like your business is struggling to incorporate a new offering model. In its current state, Connect is not a beta feature -- it's a gotcha, something that your existing users need to warn others about. Don't rely on this. Don't let "beta" make you think it's in good shape. Use something else. If your service invalidated my API key, you have to tell me why. If your service is having issues, you have to be able to display a status message. If your service is in degraded state, you have to provide updates and ETA suitable to whatever service level you intend to offer. Thank you, and I hope this commentary can be taken in the collaborative spirit in which it was intended. inb4 your expectations are unreasonable, git gud, what do you want from the team, works for me, don't like it don't use it, etc. Trying to help build a better product here.