Skip to content

Feat/emover fixes#765

Merged
coodos merged 3 commits intomainfrom
feat/emover-fixes
Feb 4, 2026
Merged

Feat/emover fixes#765
coodos merged 3 commits intomainfrom
feat/emover-fixes

Conversation

@sosweetham
Copy link
Copy Markdown
Member

@sosweetham sosweetham commented Feb 4, 2026

Description of change

updates emover styling and adds evault id to the whois endpoint of evault core

Issue Number

n/a

Type of change

  • Update (a change which updates existing functionality)
  • Fix (a change which fixes an issue)

How the change has been tested

manual

Change checklist

  • I have ensured that the CI Checks pass locally
  • I have removed any unnecessary logic
  • My code is well documented
  • I have signed my commits
  • My code follows the pattern of the application
  • I have self reviewed my code

Summary by CodeRabbit

  • New Features

    • Added logout button in app header for authenticated users.
    • Enhanced loading states with spinner indicators throughout the app.
  • Bug Fixes

    • Improved form button behavior and accessibility.
  • Documentation

    • Updated eVault API documentation with evaultId field descriptions.
  • Style

    • Redesigned login page with enhanced card-based layout and visual hierarchy.
    • Refreshed home page provider selection with grid-based button cards.
    • Updated migration page with improved card styling and typography.
    • Applied consistent global styling with updated fonts and spacing.

@sosweetham sosweetham requested a review from coodos as a code owner February 4, 2026 08:48
@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai bot commented Feb 4, 2026

📝 Walkthrough

Walkthrough

The pull request adds an evaultId identifier field to the eVault /whois endpoint with registry-based resolution logic in the backend, updates related documentation, extends the eVault instance configuration with this field, and redesigns the Emover frontend authentication and application layouts with improved UI components, styling, and visual hierarchy.

Changes

Cohort / File(s) Summary
Documentation Updates
docs/docs/Infrastructure/eVault-Key-Delegation.md, docs/docs/Infrastructure/eVault.md
Added evaultId field documentation to /whois endpoint examples and descriptions, explaining its role as the eVault instance identifier matching the Registry configuration.
eVault Core API
infrastructure/evault-core/src/core/http/server.ts, infrastructure/evault-core/src/index.ts
Implemented evaultId field in /whois response schema; added registry-based resolution logic to fetch evaultId via /resolve endpoint; extended evaultInstance configuration with EVAULT_ID environment variable; clarified numeric parsing in logs endpoint.
Emover Frontend - Authentication & Layout
platforms/emover/src/app/layout.tsx, platforms/emover/src/app/(app)/layout.tsx, platforms/emover/src/app/(auth)/login/page.tsx
Removed Google Font Inter import; added logout functionality to app layout with logout button in header; redesigned login page with new card-based UI, decorative elements, and improved visual hierarchy.
Emover Frontend - App Pages
platforms/emover/src/app/(app)/page.tsx, platforms/emover/src/app/(app)/migrate/page.tsx
Redesigned page layouts with bordered card styling, updated provisioner selector to grid of button cards, enhanced loading states with spinners, adjusted typography and color tokens, simplified useAuth hook usage, and refined component structure.
Emover Frontend - Global Styling
platforms/emover/src/app/globals.css
Added global body font-family and background-color styles to establish baseline visual consistency across the application.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

  • Feat/signature verification library #464: Both modify the /whois and registry resolution flow; the main PR surfaces evaultId on /whois with registry lookup logic that enables downstream signature validation.
  • refactor:control-panel #469: Both PRs introduce and propagate eVault identifiers (evaultId/ename) through registry-based resolution and response payloads.
  • Feat/provisioner secret use #299: Both PRs modify the /whois endpoint implementation in infrastructure/evault-core/src/core/http/server.ts and related eVault wiring.

Suggested labels

evault-refactor

Suggested reviewers

  • coodos
  • xPathin

Poem

🐰 A vault identifier now flows,
Through registries where data goes,
The UI blooms with cards anew,
While logout buttons shine on cue,
*~ A rabbit's ode to structured views* ✨

🚥 Pre-merge checks | ✅ 1 | ❌ 2
❌ Failed checks (1 warning, 1 inconclusive)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
Title check ❓ Inconclusive The title 'Feat/emover fixes' is vague and overly generic, using non-descriptive terms that do not convey meaningful information about the changeset. Use a more specific title that highlights the primary change, such as 'Add evaultId to whois endpoint and update emover UI styling' or 'Add eVault ID support to whois endpoint and improve emover styling'.
✅ Passed checks (1 passed)
Check name Status Explanation
Description check ✅ Passed The description follows the template structure with all required sections present (issue number, type of change, testing, and checklist), though some sections lack detail.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch feat/emover-fixes

Important

Action Needed: IP Allowlist Update

If your organization protects your Git platform with IP whitelisting, please add the new CodeRabbit IP address to your allowlist:

  • 136.113.208.247/32 (new)
  • 34.170.211.100/32
  • 35.222.179.152/32

Reviews will stop working after February 8, 2026 if the new IP is not added to your allowlist.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@coodos coodos merged commit 63f8fee into main Feb 4, 2026
5 of 6 checks passed
@coodos coodos deleted the feat/emover-fixes branch February 4, 2026 08:51
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
docs/docs/Infrastructure/eVault-Key-Delegation.md (1)

140-152: ⚠️ Potential issue | 🟡 Minor

Document the nullable evaultId case in the /whois response.

The response schema allows string | null, but the text implies it’s always present. Add an explicit null note to avoid client assumptions.

✏️ Suggested doc tweak
-`evaultId` is the eVault instance identifier (when configured); it matches the `evault` value registered with the Registry.
+`evaultId` is the eVault instance identifier when configured; otherwise it is `null`. It matches the `evault` value registered with the Registry.
🤖 Fix all issues with AI agents
In `@docs/docs/Infrastructure/eVault.md`:
- Around line 276-297: Update the /whois documentation to explicitly state that
the evaultId field can be null (type "string | null") in responses so clients
handle it safely; modify the JSON example and the bullet describing `evaultId`
to show that it may be null (e.g., "evaultId: string | null" and note "May be
null when not configured") and reference the /whois endpoint and the evaultId
property in the explanatory text so callers implement null checks before using
the value.

In `@infrastructure/evault-core/src/core/http/server.ts`:
- Around line 164-202: Initialize evaultId from the configured value before
calling the Registry (e.g., set evaultId = evault.evaultId or
process.env.EVAULT_ID) so the response contains the configured ID if registry
resolution fails; then keep the existing registry resolution logic that only
overrides evaultId when resolveResponse.data?.evault is present (or skip the
axios call entirely if evaultId is already truthy). Update the block that
defines evaultId, registryUrlForResolve, and the axios resolution to respect
this fallback and only replace the pre-set evaultId on successful resolution.
🧹 Nitpick comments (1)
platforms/emover/src/app/(app)/migrate/page.tsx (1)

82-130: Stop polling after terminal status to reduce redundant requests.

Once the status is completed or failed, the interval can be cleared to avoid extra traffic.

♻️ Suggested change
-        const pollStatus = async () => {
+        let interval: ReturnType<typeof setInterval> | null = null;
+        const pollStatus = async () => {
             try {
                 const response = await apiClient.get(`/api/migration/status/${migrationId}`);
                 const data = response.data;
@@
-                    if (data.status === "completed") {
+                    if (data.status === "completed") {
                         setIsActivated(true);
                         setQrData(null);
+                        if (interval) {
+                            clearInterval(interval);
+                            interval = null;
+                        }
                     } else if (data.status === "failed") {
                         setError(data.error || "Migration failed");
+                        if (interval) {
+                            clearInterval(interval);
+                            interval = null;
+                        }
                     }
                 }
             } catch (error) {
                 console.error("Error polling migration status:", error);
             }
         };
@@
-        const interval = setInterval(pollStatus, 2000);
+        interval = setInterval(pollStatus, 2000);
 
-        return () => clearInterval(interval);
+        return () => interval && clearInterval(interval);

Comment on lines 276 to +297
```json
{
"w3id": "@user-a.w3id",
"evaultId": "@evault-identifier",
"keyBindingCertificates": [
"eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9...",
"eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9..."
]
}
```

- `w3id`: The W3ID (eName) from the request.
- `evaultId`: The eVault instance identifier (when configured via `EVAULT_ID`). Matches the `evault` value registered with the Registry.
- `keyBindingCertificates`: JWTs binding the eName to public keys.

**Example**:
```bash
curl -X GET http://localhost:4000/whois \
-H "X-ENAME: @user-a.w3id"
```

**Use Case**: Platforms use this endpoint to retrieve public keys for signature verification.
**Use Case**: Platforms use this endpoint to retrieve public keys for signature verification and the eVault instance id for routing or auditing.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Clarify evaultId nullability in the /whois docs.

The API returns string | null; make the docs explicit so clients handle null safely.

✏️ Suggested doc tweak
-- `evaultId`: The eVault instance identifier (when configured via `EVAULT_ID`). Matches the `evault` value registered with the Registry.
+- `evaultId`: The eVault instance identifier (when configured via `EVAULT_ID`); otherwise `null`. Matches the `evault` value registered with the Registry.
🤖 Prompt for AI Agents
In `@docs/docs/Infrastructure/eVault.md` around lines 276 - 297, Update the /whois
documentation to explicitly state that the evaultId field can be null (type
"string | null") in responses so clients handle it safely; modify the JSON
example and the bullet describing `evaultId` to show that it may be null (e.g.,
"evaultId: string | null" and note "May be null when not configured") and
reference the /whois endpoint and the evaultId property in the explanatory text
so callers implement null checks before using the value.

Comment on lines +164 to 202
// Resolve eName via Registry (same logic as /resolve) to get evault id
let evaultId: string | null = null;
const registryUrlForResolve =
process.env.PUBLIC_REGISTRY_URL || process.env.REGISTRY_URL;
if (registryUrlForResolve) {
try {
const resolveResponse = await axios.get<{
ename: string;
uri: string;
evault: string;
originalUri?: string;
resolved?: boolean;
}>(
new URL(
`/resolve?w3id=${encodeURIComponent(eName)}`,
registryUrlForResolve,
).toString(),
{ timeout: 10000 },
);
if (resolveResponse.data?.evault) {
evaultId = resolveResponse.data.evault;
}
} catch (error) {
// 404 or network error: evault not registered for this eName, or registry unavailable
if (
axios.isAxiosError(error) &&
error.response?.status !== 404
) {
console.error(
"Error resolving eName via Registry for whois evaultId:",
error.message,
);
}
}
}
const result = {
w3id: eName,
evaultId,
keyBindingCertificates: keyBindingCertificates,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Return configured evaultId even when Registry resolution fails.

evaultId is currently populated only from /resolve. If the Registry is unavailable (or the eName isn’t registered), the response returns null even when EVAULT_ID is configured and passed in. Initialize from evault.evaultId and only override on successful resolution (optionally skip the call when already set).

🛠️ Suggested fix (fallback to configured value)
-            let evaultId: string | null = null;
+            let evaultId: string | null =
+                typeof evault?.evaultId === "string" ? evault.evaultId : null;
             const registryUrlForResolve =
                 process.env.PUBLIC_REGISTRY_URL || process.env.REGISTRY_URL;
-            if (registryUrlForResolve) {
+            if (registryUrlForResolve && !evaultId) {
                 try {
                     const resolveResponse = await axios.get<{
                         ename: string;
                         uri: string;
                         evault: string;
🤖 Prompt for AI Agents
In `@infrastructure/evault-core/src/core/http/server.ts` around lines 164 - 202,
Initialize evaultId from the configured value before calling the Registry (e.g.,
set evaultId = evault.evaultId or process.env.EVAULT_ID) so the response
contains the configured ID if registry resolution fails; then keep the existing
registry resolution logic that only overrides evaultId when
resolveResponse.data?.evault is present (or skip the axios call entirely if
evaultId is already truthy). Update the block that defines evaultId,
registryUrlForResolve, and the axios resolution to respect this fallback and
only replace the pre-set evaultId on successful resolution.

@coderabbitai coderabbitai bot mentioned this pull request Mar 30, 2026
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants