AI SDK fixes, fixes to shared,upgrade dependencies

[dinmukhamedm]

Important

This pull request introduces Azure AD authentication, enhances the SpanView component, updates configurations for ESLint, Tailwind, and Next.js, and upgrades several dependencies.

• Authentication:
  • Add Azure AD authentication support in auth.ts.
  • Update features.ts to include AZURE_AUTH feature toggle.
• UI Components:
  • Enhance SpanView component with new span-view-store.tsx for state management.
  • Update jsx-renderer.tsx to improve template rendering.
• Configuration:
  • Update eslint.config.ts for better import sorting and unused import detection.
  • Modify next.config.js to enhance security headers and enable Turbopack.
  • Adjust tailwind.config.js to include new font settings and animations.
• Dependencies:
  • Upgrade various dependencies in package.json, including AI SDKs and Next.js.
  • Add @mux/mux-player-react for video handling.
• Miscellaneous:
  • Update utils.ts with new time formatting functions.
  • Add new fonts in fonts.ts for improved typography.

^{This description was created by for 7287804. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to 7287804 in 4 minutes and 19 seconds. Click for details.

• Reviewed 9754 lines of code in 68 files
• Skipped 29 files when reviewing.
• Skipped posting 18 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. frontend/components/ui/template-renderer/jsx-renderer.tsx:19

• Draft comment:
  The Content-Security-Policy meta tag on line 19 permits 'unsafe-inline' and 'unsafe-eval'. In a sandboxed iframe this may be necessary, but it can weaken security. Consider tightening the policy or adding a clear comment explaining why these allowances are required.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

2. frontend/lib/auth.ts:20

• Draft comment:
  The provider configs use non-null assertions (e.g. process.env.AUTH_AZURE_AD_CLIENT_ID!) which assume these environment variables are always set. Consider adding explicit error handling or default values to avoid runtime crashes in development.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

3. frontend/lib/utils.ts:16

• Draft comment:
  The fetcher functions assume process.env.BACKEND_URL is defined. It would be more robust to add a check and throw a clear error if BACKEND_URL is missing.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

4. frontend/next.config.js:22

• Draft comment:
  Similar to the jsx-renderer, the CSP header here (lines 22-24) allows unsafe-inline and unsafe-eval. Verify that these permissions are absolutely required and consider tightening them to improve security.
• Reason this comment was not posted:
  Comment was on unchanged code.

5. frontend/package.json:103

• Draft comment:
  The React and React-DOM versions are set to '^19.1.1', which is ahead of the current stable release. Confirm that this version is intentional and that it is fully compatible with Next.js ~15.5.2.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to confirm their intention regarding the versioning of React and React-DOM, which violates the rule against asking for confirmation of intention. It also touches on dependency versions, which is another area we should avoid commenting on unless we recognize the libraries and have specific knowledge about them.

6. app-server/Cargo.lock:5493

• Draft comment:
  It appears that the package name on line 5493 is 'wasite'. Is this a typographical error? If the intended package name is 'wasi', please update accordingly.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

7. frontend/app/layout.tsx:7

• Draft comment:
  There's a possible typo in the import statement on this line: 'import { manrope,sans } from '@/lib/fonts';'. It looks like a space might be missing after the comma. If this is unintentional, please update it to 'import { manrope, sans } from '@/lib/fonts'; for better readability.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment is technically correct about the missing space, this is an extremely minor formatting issue. Most IDEs auto-format on save, and this kind of spacing issue would typically be caught by ESLint or Prettier. It's not a logic issue or something that affects functionality. The missing space could be indicative of disabled auto-formatting or linting, which might be worth addressing at a project level. Even if auto-formatting is disabled, this is too minor of an issue to warrant a PR comment. It would be better addressed through proper tooling setup. Delete this comment as it's too minor and would typically be handled by code formatting tools.

8. frontend/app/policies/cookies/page.tsx:8

• Draft comment:
  There is an extraneous trailing space after the date in 'Last updated August 19, 2025 '. Consider removing the extra space.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment is technically correct, trailing spaces in text content are extremely minor styling issues that don't affect functionality. This is a cookie policy page where exact formatting is not critical. The comment feels overly pedantic and doesn't improve code quality in any meaningful way. The trailing space could potentially cause inconsistent rendering across browsers or when copying text. Maybe it's worth maintaining pristine text content. Browser rendering and text selection behavior with trailing spaces is well-understood and stable. This level of nitpicking on legal text formatting creates noise without adding value. Delete this comment as it's too minor of an issue to warrant attention in code review.

9. frontend/app/policies/privacy/page.tsx:86

• Draft comment:
  There is a missing space between "Services" and the opening parenthesis in the phrase "Services(such as the date/time stamps...". Consider adding a space: "Services (such as...".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While technically correct that there should be a space there, this is an extremely minor formatting issue in a privacy policy document. The meaning is perfectly clear either way. The rules state not to make comments that are obvious or unimportant. A missing space in legal text that doesn't impact readability or meaning falls into that category. The space is technically missing and proper spacing does contribute to professional polish. Legal documents should be properly formatted. While proper formatting is good, this is such a minor issue that it doesn't warrant a PR comment. The rules explicitly say not to make obvious or unimportant comments. The meaning is clear either way. Delete this comment as it points out an extremely minor formatting issue that doesn't impact meaning or functionality.

10. frontend/app/policies/privacy/page.tsx:135

• Draft comment:
  In the phrase "(i.e. , legal basis)" there is an extra space before the comma. It should likely read "(i.e., legal basis)".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While technically correct about the extra space, this is an extremely minor formatting issue that doesn't affect functionality or readability in any meaningful way. The rules state not to make comments that are obvious or unimportant. Spacing issues like this are very minor and don't warrant a PR comment. The spacing inconsistency could be seen as unprofessional in a legal document like a privacy policy. Multiple small issues can add up to make a document look sloppy. While consistency is good, this level of nitpicking about spaces in text content is too minor to warrant a PR comment. The privacy policy is still perfectly readable and legally valid. Delete this comment as it violates the rule about not making comments that are obvious or unimportant. A single extra space is too minor of an issue to flag in a PR review.

11. frontend/app/policies/privacy/page.tsx:141

• Draft comment:
  Similarly, in phrases like "(i.e , consent)" in several places, remove the extra space before the comma so that it reads "(i.e., consent)".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the suggestion is technically correct about proper punctuation, this is an extremely minor formatting issue in a legal document. The current spacing doesn't impact functionality or readability significantly. PR comments should focus on more substantial issues. Additionally, there may be multiple instances of this throughout the document that would need to be fixed consistently. The spacing issue could be considered part of maintaining consistent, professional formatting throughout the codebase. Multiple small formatting issues can add up to make a document look less polished. While consistency is valuable, this level of nitpicking about spaces in a legal document is excessive for a PR review. The current spacing doesn't meaningfully impact the document's professionalism or readability. This comment should be removed as it focuses on an extremely minor formatting issue that doesn't significantly impact the code or document quality.

12. frontend/app/policies/privacy/page.tsx:325

• Draft comment:
  There's a missing space after a period: "personal information.You may review..." should be corrected to "personal information. You may review...".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment is technically correct about the missing space, this is a very minor formatting issue in a large legal text document. The comment doesn't point out any functional issues or code quality problems. It's more of a nitpick about text formatting that doesn't impact functionality or readability significantly. The space is indeed missing and fixing it would improve the text formatting slightly. Text formatting consistency could be considered important for legal documents. However, this is an extremely minor formatting issue that doesn't affect functionality or significantly impact readability. The PR review process should focus on more substantial code and functionality issues rather than nitpicking text spacing in content. This comment should be removed as it focuses on an extremely minor text formatting issue rather than substantive code or functionality concerns.

13. frontend/app/policies/terms/page.tsx:92

• Draft comment:
  Minor typographical error: There is an extra space before the period in the sentence "... internal business purpose .". Consider removing the space so it reads "internal business purpose."
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a new file being added, so any changes are relevant. The comment is technically correct - there is an extra space before the period. However, this is an extremely minor formatting issue that doesn't affect functionality or readability in any meaningful way. The rules state not to make comments that are obvious or unimportant. The extra space could be considered part of maintaining consistent, professional formatting in legal documentation where precision matters. While formatting consistency is good, this is such a minor issue that it doesn't warrant a PR comment. The effort of reviewing and addressing the comment outweighs the tiny benefit of fixing it. Delete this comment as it points out an extremely minor formatting issue that doesn't meaningfully impact the code or documentation.

14. frontend/app/policies/terms/page.tsx:120

• Draft comment:
  Typographical note: There's an extra space before the semicolon in "... jurisdiction in which you reside ;". Please remove the space to properly join the text.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% While the comment is technically correct about the extra space, this is an extremely minor formatting issue in a legal terms document. The extra space doesn't impact functionality or readability in any meaningful way. According to the rules, we should not make comments that are obvious or unimportant. The space could be considered a consistency issue since other semicolons in the document don't have spaces before them. Maybe it's worth maintaining consistent formatting. Even if it's inconsistent, this is still too minor of an issue to warrant a comment. This is a legal document where the exact formatting is less critical than the content. Delete this comment as it points out an extremely minor formatting issue that doesn't meaningfully impact the code or document.

15. frontend/app/policies/terms/page.tsx:156

• Draft comment:
  There is an extra space before the period at the end of the sentence in this list item. Consider removing the space so that it ends with "... under false pretenses."
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% This is a new file being added, so technically it is a change. However, the comment is about a very minor formatting issue - an extra space before a period. This kind of nitpicky formatting comment doesn't add value and could be distracting from more important issues. The space doesn't affect functionality or readability in any meaningful way. The space is technically incorrect formatting, and consistency in formatting can be important for code quality. Maybe this kind of attention to detail is valuable? While consistency is good, this level of nitpicking about spaces is too minor to be worth a PR comment. It adds noise without meaningful value. Delete this comment as it's too minor and nitpicky to be worth raising in a PR review.

16. frontend/app/policies/terms/page.tsx:42

• Draft comment:
  A potential typographical issue: An empty anchor tag with href="#ppyes" is present. If this is unintended, please remove or correct it.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While the comment is technically correct that there's an empty anchor tag, this appears to be part of the HTML structure of the terms of service page. The empty anchors may serve a purpose in the navigation or styling. Without more context about the intended design, removing them could break something. Additionally, this is a very minor issue that doesn't affect functionality. I could be wrong about the anchors serving a purpose - they might truly be unnecessary. And redundant/empty tags are generally not good practice. However, this is a terms of service page where the exact HTML structure may be important for legal or design reasons. Making changes to it based on general HTML best practices could be risky without understanding the requirements. The comment should be deleted. While technically accurate, modifying HTML structure in legal documents requires more context, and the issue is too minor to warrant a comment.

17. frontend/components/landing/frameworks-grid.tsx:35

• Draft comment:
  Typographical suggestion: The integration name is "LangGraph", but the associated icon (IconLangchain) and URL (langchain) suggest this might be intended to be "LangChain". Please verify and update if necessary.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While there is a mismatch, we don't have enough context to know if this is intentional. LangGraph could be a related but different product that intentionally uses LangChain's icon. The URL structure could be a coincidence. Without more context about the business logic or product requirements, we can't be certain this is a mistake. The comment assumes this is a typo without having full context about the product relationships. It could be intentionally named LangGraph while being part of the LangChain ecosystem. Given our rules state we should only keep comments when we have STRONG EVIDENCE of an issue, this uncertainty means we should err on the side of removing the comment. Delete the comment since we don't have enough context to be certain that this naming inconsistency is actually a mistake rather than intentional.

18. frontend/components/landing/landing.tsx:726

• Draft comment:
  There appears to be an extra curly bracket (}) in the closing h3 tag (</h3>}). It should probably just be </h3>. Please remove the extra }.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

Workflow ID: wflow_1bpeQCOyS8aVTftV

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

The call to migrate(db as any, ...) casts db to any. Using 'any' bypasses type safety. Consider properly typing the database instance or refining the migration API.