[Bug] Markdown rendering issues with formatting

[gnunn1]

Bug Description
I'm using the component as a chatbot interface for an LLM chatbot that returns the bot responses in markdown. The formatting for ordered lists is off as I get the list number on one line and then the text on a new line instead of it being all on the same line.

Additionally HTML links are not being automatically rendered as links without explicit Markdown link formatting which unfortunately my LLM is not doing.

Steps To Reproduce
Steps to reproduce the bug behavior:

1. Provide Bot content that returns an ordered list in Markdown, content I'm using is pasted in the next comment.

Expected behavior
List number and line should be on the same line

Screenshots

Desktop (please complete the following information):

• OS: Arch Linux
• Browser: Chrome (latest stable)

Additional context
I've been using the HTML renderer with the marked library and it renders things more optimally in terms of these issues but results in more spacing then I would I like. Here is what it looks like using that combo:

[gnunn1]

Content to test with:

<think>
Okay, so I'm looking at this deployment configuration for a PostgreSQL database in OpenShift. The user wants to know if it follows best practices. Let me go through it step by step.

First, I notice the deployment uses a Deployment object, which is good because DeploymentConfig is deprecated. That's a positive sign. The spec has replicas set to 1, which makes sense for a database that's not sharded, but maybe adding a replica set or a load balancer could help with availability.

The strategy is set to "Recreate", which is straightforward but might cause downtime since the old pod is terminated before the new one starts. For a database, maybe a rolling update would be better to minimize downtime, but that depends on the database's ability to handle replication during the update.

Looking at the container spec, the image is from the OpenShift image registry, which is secure. The imagePullPolicy is "IfNotPresent", which is efficient. The resources are limited to 512Mi of memory, which is good for resource management but might need adjustment based on actual usage.

The environment variables are pulling values from secrets, which is secure. The liveness and readiness probes are using custom checks, which is better than default ones. However, the initial delay for liveness is 120 seconds, which might be too long, potentially causing the pod to take longer to recover.

Volumes are using a persistent volume claim, which is correct for a database. The security context is set to non-privileged, which is a good security practice.

Networking-wise, the deployment doesn't specify any affinity or anti-affinity, so the pods could end up on the same node, which isn't ideal for high availability. Adding node affinity or anti-affinity would improve this.

Annotations like Argo CD's tracking ID and sync wave are present, which helps with CI/CD, so that's a plus.

Overall, the deployment is well-structured but could benefit from some improvements like scaling, a more sophisticated strategy, resource limits, and networking considerations. It's a solid foundation but has areas for enhancement to align fully with best practices.
</think>

The deployment configuration appears to be well-structured and follows many best practices for running a PostgreSQL database in Kubernetes (and OpenShift). Below is an analysis of the key aspects of the deployment:

### 1. **Use of Deployment Object**
   - The deployment uses the `Deployment` object, which is the recommended resource for managing replication and updates to pods in Kubernetes. This is in line with best practices, as `DeploymentConfig` objects are deprecated in OpenShift 4.14 and later.

### 2. **Replicas and Scaling**
   - The deployment specifies `replicas: 1`, which is appropriate for a single-instance database deployment. However, consider adding a Horizontal Pod Autoscaler (HPA) or Vertical Scaling Policy to automatically adjust resources based on workload.

### 3. **Strategy**
   - The strategy is set to `Recreate`, which is a simple and reliable method for ensuring a clean deployment. However, this strategy causes downtime during the update. For a database, consider using a rolling update strategy with proper database replication and synchronization to minimize downtime.

### 4. **Resource Requests and Limits**
   - The deployment specifies `limits.memory: "512Mi"`, which is a good practice to ensure that the pod does not overconsume resources. However, consider adding requests for memory and CPU to ensure the pod is scheduled appropriately.

### 5. **Security**
   - The deployment uses a non-privileged security context, which is a good practice to reduce the attack surface.
   - The database credentials are pulled from secrets, which is a best practice for securing sensitive data.

### 6. **Liveness and Readiness Probes**
   - The deployment includes both liveness and readiness probes with custom checks. This is a best practice to ensure the database is healthy before considering it ready or alive.

### 7. **Volume Provisioning**
   - The deployment uses a persistent volume claim (`claimName: "postgresql"`) for storage, which is appropriate for a database. Consider using a PersistentVolume with a storage class that provides durability and availability.

### 8. **Networking**
   - The deployment does not include any specific networking configurations (e.g., Service, Ingress, or Affinity). Consider adding a Service to expose the database to other components and a NetworkPolicy to control traffic.

### 9. **Annotations**
   - The deployment includes annotations for Argo CD, which is a good practice for CI/CD and application delivery.

### 10. **Observability**
   - The deployment does not include any observability tools (e.g., Prometheus, Grafana). Consider adding monitoring and logging to ensure the database is performing well and to troubleshoot issues.

### 11. **Updates and Rollbacks**
   - The deployment does not specify any update or rollback policies. Consider adding an `updateStrategy` to control the update behavior and a `rollback` section to define how to roll back to a previous version.

### 12. **Tolerations and Affinity**
   - The deployment does not include any tolerations or affinity settings. Consider adding tolerations for specific node types or zones to improve availability.

### Conclusion
The deployment configuration is generally well-structured and follows many best practices for running a PostgreSQL database in Kubernetes. However, there are a few areas where improvements could be made to further align with best practices, such as adding scaling policies, improving the deployment strategy, and enhancing security and observability.

---

DeploymentConfig [apps.openshift.io/v1]: https://docs.openshift.com/container-platform/4.18/rest_api/workloads_apis/deploymentconfig-apps-openshift-io-v1.html
Understanding deployments: https://docs.openshift.com/container-platform/4.18/applications/deployments/what-deployments-are.html
Deployment [apps/v1]: https://docs.openshift.com/container-platform/4.18/rest_api/workloads_apis/deployment-apps-v1.html
ClusterServiceVersion [operators.coreos.com/v1alpha1]: https://docs.openshift.com/container-platform/4.18/rest_api/operatorhub_apis/clusterserviceversion-operators-coreos-com-v1alpha1.html

[tjtanjin]

Hey @gnunn1! Thank you for raising this up. I've been a bit busy recently preparing for the final stretch to get v2 stable but I'll look at this very soon 😊 If you have discord, feel free to join the server - would also make things a little easier if more clarifications are needed.

[gnunn1]

I didn't realize the markdown wrapper was pluggable so I ended up writing a quick wrapper using marked instead of react-markdown and it seems to be working better for me (note I also have some minimal CSS being used here as well for the lists and line spacing, haven't tested removing it yet).

Finally I'm an intermittent Typescript developer so I'm sure my code could be bettter :)

import * as React from "react";
import * as dompurify from 'dompurify';

import { marked } from "marked";

const purifier = dompurify['default'] as dompurify.DOMPurify;

const MarkedWrapper = ({
    children
}: {
    children: React.ReactNode
}) => {
    const markdown = typeof children === "string" ?
        children.replace(/&/g, "&")
            .replace(/</g, "&lt;")
            .replace(/>/g, "&gt;")
            .replace(/"/g, "&quot;")
            .replace(/'/g, "&#039;") :
        "";
    const text = marked(purifier.sanitize(markdown), { async: false });
    return (
        <div dangerouslySetInnerHTML={{ __html: text }} />
    );
};

export default MarkedWrapper;

[gnunn1]

Tested with another prompt and still some spacing issues I need to work out with CSS. This extension is running in the Argo CD UI (a GitOps tool) and it has some of it's own generic CSS which is presumably having an impact as well.

[tjtanjin]

Hey @gnunn1, I made some improvements in the latest version of markdown renderer. Do give it a try! 😊

[sumansuhag]

1. First item
2. Second item

Example

import ReactMarkdown from 'react-markdown'
import remarkGfm from 'remark-gfm'

<ReactMarkdown
children={content}
remarkPlugins={[remarkGfm]} // fixes list rendering
components={{
a: ({ node, ...props }) => <a {...props} target="_blank" rel="noreferrer" />
}}
/>
ol {
padding-left: 1.5em;
}
li {
margin-bottom: 0.25em;
}
<ReactMarkdown
children={content}
remarkPlugins={[remarkGfm]}
rehypePlugins={[rehypeRaw]} // allows tags to render
allowDangerousHtml={true} // use only in safe environments
/>
const linkified = text.replace(
/(https?://[^\s]+)/g,
'$1'
)

[sumansuhag]

Hiii
Thanks for reporting this!

You're encountering two common Markdown rendering issues:

1. Ordered lists breaking lines — likely due to missing remark-gfm or bad CSS.
2. HTML links not being rendered — requires rehype-raw if using react-markdown, or fallback linkification.

Suggestions:

• Use remark-gfm to fix list formatting.
• Enable rehype-raw if you're okay with rendering raw HTML tags like <a>.
• You may also preprocess responses to auto-linkify raw URLs.

Let us know your rendering stack and we can suggest specific patches! 🚀

[sumansuhag]

Markdown rendering inconsistencies between LLM output and specific UI components, especially regarding list formatting and HTML link parsin

[sumansuhag]

To create a smooth rendering process, pick a good Markdown parser and make sure to include a step to normalize the content before rendering. This will help keep the formatting from LLMs consistent for better display.