env import and single secret creation conflict resolution

[teyim]

🔍 Overview

This PR improves duplicate secret-key handling across environment imports and inline secret editing.

Previously, importing .env content containing repeated keys could produce ambiguous results because users could not explicitly choose which value to retain. Duplicate keys created or edited directly in secret rows also lacked clear, actionable feedback. (Related to #946 )

This change introduces a conflict-resolution workflow for imports and inline duplicate-key validation for environment and app secret rows.

💡 Proposed Changes

Import conflict resolution

• Add a conflict-resolution step to single- and multi-environment import dialogs.
• Detect repeated keys without collapsing their original occurrences.
• Prompt users to resolve duplicates containing different values before continuing.
• Automatically resolve repeated keys whose values are identical.
• Allow users to:
  • Select an individual value for each conflicting key.
  • Reveal or hide secret values.
  • Keep the first occurrence for all conflicts.
  • Keep the last occurrence for all conflicts.
  • Reset all conflict selections.
• Display resolution progress and prevent continuing while conflicts remain unresolved.

Inline duplicate-key validation

• Detect duplicate keys in environment and app secret rows.
• Highlight conflicting key inputs.
• Display an actionable message referencing the other conflicting row.
• Exclude secrets staged for deletion from duplicate detection.
• Include dynamic and rotating secret keys when checking for conflicts.

Internal improvements

• Add reusable .env parsing, grouping, and conflict-resolution utilities.
• Add a shared key-position index for case-insensitive duplicate lookup and accurate row references.
• Replace duplicated key-position bookkeeping in the environment and app secret views.
• Preserve ph-no-capture protection for sensitive values and validation content.
• Use smaller monospaced typography for secret keys and values.

🖼️ Screenshots or Demo

Development.Example.App.testing.Phase.Console.July.mp4

📝 Release Notes

Added an explicit conflict-resolution workflow for duplicate keys found during .env imports. Users can now review conflicting values and select which occurrence to retain before importing.

Duplicate keys entered directly in environment or app secret rows are now highlighted with actionable validation feedback.

There are no breaking changes or migration requirements.

❓ Open Questions

If there are aspects of the changes that you're unsure about or would like feedback on, list them here.

🧪 Testing

Added and updated tests covering:

• Parsing .env content without collapsing duplicate keys.
• Grouping duplicate occurrences.
• Detecting duplicates case-insensitively.
• Resolving conflicts using individual selections.
• Selecting the first or last occurrence in bulk.
• Handling identical duplicate values.
• Handling empty and multiline values.
• Excluding secrets staged for deletion.
• Building reusable key-position indexes.
• Preserving displayed row numbers for excluded entries.
• Rendering accessible duplicate-key validation messages.
• Rendering and interacting with the conflict-resolution component.

🎯 Reviewer Focus

Suggested review order:

1. frontend/utils/secrets.ts

   • .env parsing and conflict-resolution behavior.
   • Duplicate detection and reusable key-position indexing.

2. frontend/components/environments/secrets/import/EnvConflictResolution.tsx

   • Conflict selection and bulk actions.
   • Value visibility and accessibility.

3. Import dialogs

   • SingleEnvImportDialog.tsx
   • MultiEnvImportDialog.tsx
   • Integration of the conflict-resolution step into existing import flows.

4. Inline secret rows

   • SecretRow.tsx
   • AppSecretRow.tsx
   • Inline duplicate-key feedback and accessibility attributes.

5. Environment and app secret lists

   • Duplicate detection across regular, rotating, and dynamic secrets.
   • Exclusion of secrets staged for deletion.

6. Component and utility tests

   • Expected behavior and edge-case coverage.

➕ Additional Context

• The key-position index preserves visible row numbering even when a secret is excluded from duplicate detection. This ensures validation messages reference the row number users see in the UI.
• Keys are normalized case-insensitively, so names such as API_KEY and api_key are treated as duplicates.
• No dependencies, database migrations, GraphQL schema changes, or generated types are required.

✨ How to Test the Changes Locally

Start the development stack and open https://localhost/. Import .env content containing duplicate keys with different values, confirm the conflict-resolution step appears, and verify individual selection, reveal/hide, bulk resolution, reset, and continue behavior. Also create duplicate keys directly in environment and app secret rows to confirm inline validation appears and is removed when a conflicting secret is renamed or staged for deletion.

💚 Did You...

• Ensure linting passes (code style checks)?
• Update dependencies and lockfiles (if required)
• Update migrations (if required)
• Regenerate graphql schema and types (if required)
• Verify the app builds locally?
• Manually test the changes on different browsers/devices?

[rohan-chaturvedi]

@teyim this is great work! Apologies for the delay in reviewing this. I have a few suggestions on the UX and code conventions to address:

UX

Proposed changes to the conflict dialog:

• Remove the two summary cards at the top. Stack the elements: "x conflicts remaining", then the progress bar, then "Resolved x of y" in small gray text.
• Show all values in plain text. Remove the "Reveal all" button. Keep ph-no-capture on the container.
• Add a small gray "Select a value" label above each value list.
• Move the "Resolve all conflicts" menu up, next to the "Conflicts to resolve" heading. Open the menu downward.
• Move the "Back" button to the left side of the footer.
• Animate the accordion with real heights, from grid-rows-[0fr] to grid-rows-[1fr]. Then the dialog height does not jump when the next conflict opens.

Mockup:

Code conventions

• Use the icon prop on Button for all button icons. Do not pass icons as children. See the inline suggestion.
• Use our native ProgressBar component (components/common/ProgressBar.tsx) instead of a raw <progress> element. See the inline suggestion.
• Extract a shared useEnvImportConflicts hook for the parse, conflict, and selection state. Both import dialogs duplicate this flow, and their reset logic already differs.

Happy to push these changes directly to the branch or create a separate PR for you. Let me know!

[rohan-chaturvedi]

Use the native ProgressBar component here. Add the import: import ProgressBar from '@/components/common/ProgressBar'

Suggested change

	<progress
	className="mt-2 h-1.5 w-full accent-emerald-500"
	max={conflicts.length}
	value={resolvedCount}
	aria-label={`${resolvedCount} of ${conflicts.length} conflicts resolved`}
	/>
	<ProgressBar
	percentage={(resolvedCount / conflicts.length) * 100}
	color="bg-emerald-500"
	size="sm"
	/>

[rohan-chaturvedi]

Use the icon prop for Button icons. Do not pass icons as children. The prop keeps the icon size stable and swaps it for the spinner during loading states.

Suggested change

	<Button
	variant="outline"
	onClick={() => toggleRevealed(conflict.key)}
	aria-label={`${isRevealed ? 'Hide' : 'Reveal'} all values for ${conflict.key}`}
	>
	{isRevealed ? <FaEyeSlash /> : <FaEye />}
	{isRevealed ? 'Hide all' : 'Reveal all'}
	</Button>
	<Button
	variant="outline"
	onClick={() => toggleRevealed(conflict.key)}
	aria-label={`${isRevealed ? 'Hide' : 'Reveal'} all values for ${conflict.key}`}
	icon={isRevealed ? FaEyeSlash : FaEye}
	>
	{isRevealed ? 'Hide all' : 'Reveal all'}
	</Button>

Note: if we adopt the plain-text values layout, this button goes away. The same rule applies to the chevron on "Resolve all conflicts".