radius@0.2.0

Minor Changes

• #548 @sk593 - Let users create an environment even when credential verification fails for a reason they can accept (exceptions 4.4 permissions and 4.5 cluster/cloud unreachable). The failed-verification panel now offers a Create Environment anyway action that records a durable RADIUS_VERIFICATION_BYPASSED marker on the GitHub Environment. The Environments list then reports the environment as bypassed — a distinct, deployable status labelled (verification bypassed) rather than masquerading as verified — so deploys are unblocked without discarding the real verification result. Bypass is offered only for recoverable failures (never for OIDC-trust or unknown errors), and a later genuine verification success supersedes the marker.

• #873 @sk593 - Changed: Deployments now use the latest released Radius resource types and recipe packs. The Azure and Kubernetes recipe packs define only recipes, so the deploy workflow creates the Radius environment on its own and then attaches the pack to it. Existing environments keep their recipe packs and no action is required.

• #861 @ryanwaite - Changed: Show recognizable provider service names in planned and deployed application graphs while keeping the exact concrete resource type available in node details.

Patch Changes

• #878 @kachawla - Fixed: Look the AKS cluster up in its own resource group when connecting to it during deploy, verify, and delete. The generated Azure workflows used the application's resource group, which only works while the cluster happens to live there. Environments that do not record the cluster's resource group keep using the application's, so nothing needs to be reconfigured.

• #856 @kachawla - Fixed: Allow an environment on an AKS cluster that shares its name with another cluster in the same subscription. Radius now records the cluster's resource group, so a namespace is only reported as taken when it is taken on the same cluster. Environments created before this change do not record it and are still treated as possible holders of the namespace; recreate one to clear a false conflict.

• #587 @sk593 - Fixed: Avoid redundant GitHub commits when generated Radius workflows are already up to date.

• #753 @sk593 - Fixed: Azure environment setup now grants the deploy identity the least-privilege Locks Contributor role (Azure built-in role 28bf596f-4eb7-45ce-b5bc-6cf482fec137) on the target resource group, so recipes can create and remove resource locks without broader access-management permissions. The grant is best-effort and non-fatal, like the AKS cluster role: setup continues with a warning and the exact az role assignment create command when the operator cannot create the assignment.

• #644 @nicolejms - Fixed: Show clearer Radius setup recovery guidance when workflow publication needs a fork or a pull-request merge is not enough to start credential verification.

• #655 @willdavsmith - Harden Radius Canvas application graphs against accidental secret disclosure. Canvas-generated graph artifacts and modeled or deployed graph state now retain only required resource, relationship, and provider-output metadata; non-null graph-visible Radius.Security/secrets data is rejected before the graph is saved or rendered.

• #548 @sk593 - Detect cloud credential drift on a redeploy (exception 5.2). When a deploy run fails at its cloud login/credentials step before rad deploy touches any resource — meaning an environment that verified earlier no longer authenticates because its trust or permissions changed — the deploy panel now explains that the credentials drifted and offers a Re-verify credentials action that opens the Environments list, instead of showing a raw workflow error. The failure is also stamped with a dedicated kind so the automatic repair loop leaves it for the user to re-verify rather than redeploying an unchanged, still-failing configuration.

• #548 @sk593 - Classify cloud credential-verification failures and validate the Create Environment form before dispatch. A failed verify run is now inferred canvas-side from its failed step names and log into an OIDC-trust, permissions, or unreachable-cluster/cloud category, so the progress panel explains what to fix (and lists missing permissions) instead of showing one generic message. The environment form also rejects malformed environment names before the verify workflow is dispatched.

• #782 @nicolejms - Changed: The delete confirmation now summarizes resources last reported for the selected application and environment before you type the confirmation phrase, from both the deployed graph and the deployments list. Long lists show the first several names and types, with a count of the rest. When a matching resource report is unavailable, the dialog keeps its existing warning rather than treating modeled graph nodes as deployed resources. Stopping tracking of a failed teardown is unchanged.

• #828 @nithyatsu - Fixed: Stop the graph compare view from asking for an application model forever after modeling has permanently failed. When neither compared branch has .radius/app.bicep and Copilot reports that it cannot author one, the compare view now shows the reported reason and stops re-requesting generation, and refreshing the Radius Canvas starts a fresh attempt.

• #792 @AzureMike - Fixed: Distinguish actionable application-model diagnostics from unavailable validation, report compiler and policy findings together, and preserve repair history across unavailable checks.

• #809 @sk593 - Fixed: Speed up Azure credential setup by checking App Registration ownership in parallel and resuming directly after a Service Management Reference prompt.

• #829 @AzureMike - Fixed: Allow Repo Radius control-plane bootstrap on standard private-repository runners by lowering PostgreSQL's CPU request. Update the Radius plugin, then regenerate and recommit existing pinned run-rad-commands-azure.yml, run-rad-commands-aws.yml, delete-azure.yml, delete-aws.yml, and delete-environment-azure.yml workflows to use the corrected setup action.

• #700 @kachawla - Fixed: Stop reporting an application model as permanently out of date when two copies of the Radius plugin are installed with different versions. The generator version written into .radius/app.origin.json is now the one the running extension supplies, rather than one read from whichever copy of the writer script happened to run, so the recorded version and the version the freshness check compares it against can no longer disagree. When no version is supplied the record leaves it unknown and says so, which skips the generator comparison for that model instead of recording a wrong value.

• #711 @sk593 - Fixed: Report GHCR package deletion failures in Copilot chat so users can resolve cleanup errors.

• #854 @nithyatsu - Fixed: Say "Loading the application graph" while the Graph tab reads an existing .radius/app.bicep, instead of "Generating application graph", which implied the model was being written. The progress panel switches to "Generating the application graph" only once Copilot actually starts authoring a model.

• #855 @nithyatsu - Fixed: Clicking a node in an application graph now toggles its details menu, so clicking the same node again dismisses the menu instead of leaving it open. Clicking another node still re-anchors the menu, clicking the empty pane still closes it, and clicks inside the menu keep its controls usable.

• #683 @nithyatsu - Changed: Show the application graph sooner after Copilot generates the app model. The Graph tab now re-checks for .radius/app.bicep on a 300ms, 1s, 2s, 5s, 10s backoff instead of waiting a fixed 10 seconds between polls, so a model that finishes quickly renders almost immediately while a long modeling run settles back onto the same 10 second steady-state polling interval as before.

• #788 @sk593 - Fixed: Create Radius environments separately and explicitly attach provider recipe packs so deployments remain compatible with pack-only contrib artifacts.

• #858 @AzureMike - Fixed: Preserve Bicep diagnostic columns in validation output and Canvas modeling errors, so compiler findings on the same line point to the correct locations.

• #754 @nicolejms - Fixed: Preserve the deployment graph's zoom and viewport while live status refreshes update its resources, including when a deployment finishes and the graph switches from live to terminal. Refreshes that change which resources exist, such as switching application or environment, still re-fit so the new graph is framed on screen.

• #874 @nicolejms - Fixed: Preserve Radius resource-type icon hashes and SVGs when application graphs are sanitized, saved, and rendered.

• #686 @sk593 - Verify first-time environment setup automatically from protected-branch pull requests when the default branch is proven safe from legacy verify-to-deploy workflow chains.

• #749 @willdavsmith - Fixed: Application modeling now traces native environment and configuration values to their consuming parser, matches the exact required format, and safely composes incompatible Recipe outputs or stops before publishing a broken model. The model checker also rejects Recipe aggregate-secret bindings that contradict an address-shaped native setting, including same-container helper aliases and local-module parameter pass-through.

• #742 @nicolejms - Fixed: Refresh an open application graph automatically after regenerating the workspace app.bicep.

• #785 @willdavsmith - Fixed: Reject Radius container connections that use a managed Kubernetes Secret name instead of the producer resource ID.

• #864 @nithyatsu - Fixed: Stop application modeling from downloading a Node.js runtime when node is not on the shell's PATH. The extension now resolves an existing Node.js installation — including Homebrew, Volta, scoop, Chocolatey, nvm, and nvm-windows locations — checks that it is Node.js 18 or newer, and hands its absolute path to the modeling skill, which runs its scripts through that interpreter. When no supported installation can be found, modeling stops and asks you to install Node.js — naming any too-old installations it found — instead of installing software on your machine.

• #786 @kachawla - Changed: Application modeling guidance now states sensitivity as a rule about the schema node rather than a list of known cases. Guidance already required a @secure() parameter for a sensitive property and for a value placed in an authored Radius.Security/secrets resource, but named those two cases specifically, so a sensitive field in any other shape was left to inference: a leaf nested inside a plain object, a property that compiles to a secureObject and takes one secure parameter, and the same fields on custom resource types a modeling run authors, whose x-radius-sensitive flags are compiled into the published extension and enforced exactly as a predefined type's are. Guidance also now states what may be assigned once a node is marked — only a @secure() parameter referenced by name, never a literal, a parameter declared without @secure(), or a string interpolation, including one whose operands are all secure.

  Changed: A secure-value violation now explains how to repair it. Radius reports these findings with no severity, so they printed as a warning that nonetheless failed the build, and the message named the rejected property without naming a remedy. use-secure-value-for-secure-inputs, secure-secrets-in-params, and secure-parameter-default now carry the fix, so a repair attempt is spent on the correction rather than on rediscovering the rule.

  Fixed: Guidance no longer reads a sensitive Recipe output as something the application must supply. A schema can mark one node both sensitive and read-only, and a resource type may declare a sensitive output for a credential its Recipe generates. The rule to assign a @secure() parameter now applies only to writable sensitive nodes; a sensitive read-only output is left unset and read through the Recipe's secrets result, as any other output is. The secure-secrets-in-params remedy also distinguishes its two repairs, because the rule reads a parameter's name rather than its value: add @secure() when the parameter carries the credential, but rename it when it carries a Radius.Security/secrets resource ID, where adding @secure() would only trade the warning for a secure-parameter-target failure.

  Fixed: The registry-credentials Secret in the container-image guidance no longer specifies a definition that cannot compile. It declared registryUsername as a plain parameter and assigned it to the Secret's data.username.value, which the schema marks sensitive, so following the instruction produced use-secure-value-for-secure-inputs and failed the build. Both parameters are now @secure(), in the worked example and in every rule that referenced them.

  Fixed: The worked examples for authored Secrets no longer show definitions that cannot compile. The canonical Radius.Security/secrets example assigned an administrator username as a literal, and the config-file delivery example inlined a configuration file the same way; both sit in data.<key>.value, which the schema marks sensitive, so each produced use-secure-value-for-secure-inputs. Both now take their value from a @secure() parameter, and the surrounding rules say why: every value in an authored Secret's data is sensitive because of where it is stored, not because of what it holds, so the rule covers a username or a configuration file as much as a password. The guidance also states the contrast that made this confusing — the same administrator name stays a plain literal on a backing resource's own non-sensitive username property.

• #781 @nicolejms - Fixed: Explain failed deployment graph nodes with cancellation, workflow timeout, monitoring timeout, or concise Radius error messages. Preserve resource-specific failures, remove stale progress text from successful nodes, and accept later terminal results only with verified deployment identity. Monitoring timeouts warn that the workflow may still be running without allowing an unsafe automatic redeploy.

• #718 @nicolejms - Fixed: Keep single-color resource-type icons legible in the application graph. Icons that a resource type pack draws in currentColor now follow the canvas theme in node cards and the legend instead of always painting black, which made them nearly invisible in dark mode. Multi-color icons, remote icons, and built-in glyphs are unchanged.

• #774 @sk593 - Fixed: Generated app models now warn that the registry credential Secret's name value must remain radius-ghcr-registry-creds because image pushes depend on that fixed value.

• #684 @nicolejms - Fixed: Run managed Radius CLI commands on Windows without detaching them from the automation caller, allowing windowless execution and caller-owned process-tree cancellation with current Radius builds.