Change Diff Syntax

[0x4007]

As it turns out, GitHub flavored markdown includes these handy color indicators. We can use the same color keys but instead of diff syntax, we use this syntax.

This should be applied across all kernel and plugin messages.

It might even be handy to rename the methods in our logger if its still attached to posting comments. The inspiration behind the rename is so that the class of message is no longer subjective.

logger.info();
logger.success();
logger.redirect();
logger.clientError();
logger.serverError();

Status Codes

Based on HTTP status codes, we should color code the responses. The only problem is that some of the headers can be misleading, but it does look a lot more aesthetically pleasing than the diffs. The left border in particular I think is a great minimal representation of the status.

Note

1xx

Tip

2xx

Important

3xx

Warning

4xx

Caution

5xx

Source Code

> [!NOTE]
> 1xx

> [!TIP]
> 2xx

> [!IMPORTANT]
> 3xx

> [!WARNING]
> 4xx

> [!CAUTION]
> 5xx

About HTTP Status Code Classes

HTTP status codes are standardized codes returned by web servers to indicate the result of a client's request. These codes are grouped into five classes, each signifying a different category of response:

---

1xx: Informational

Description: The 1xx class of status codes indicates that the server has received the request and is continuing the process. These are provisional responses, providing interim information while the server continues to process the request.

Common Status Codes:

• 100 Continue: Indicates that the initial part of the request has been received and the client should continue with the rest of the request.
• 101 Switching Protocols: Informs the client that the server is switching to a different protocol as requested.
• 102 Processing (WebDAV): Signals that the server has received and is processing the request, but no response is available yet.

---

2xx: Success

Description: The 2xx class signifies that the client's request was successfully received, understood, and accepted by the server.

Common Status Codes:

• 200 OK: The request has succeeded. The meaning varies depending on the HTTP method used.
• 201 Created: The request has been fulfilled, resulting in the creation of a new resource.
• 202 Accepted: The request has been accepted for processing, but the processing is not complete.
• 204 No Content: The server successfully processed the request and is not returning any content.
• 206 Partial Content: The server is delivering only part of the resource due to a range header sent by the client.

---

3xx: Redirection

Description: The 3xx class indicates that further action is needed to complete the request. This usually means a redirection to a different resource.

Common Status Codes:

• 301 Moved Permanently: The resource has been permanently moved to a new URL.
• 302 Found: The resource resides temporarily under a different URL.
• 303 See Other: The response can be found under a different URI and should be retrieved using a GET method.
• 304 Not Modified: Indicates that the resource has not been modified since the last request.
• 307 Temporary Redirect: The request should be repeated with another URI; however, future requests should still use the original URI.

---

4xx: Client Error

Description: The 4xx class signifies errors that appear to have been caused by the client. These codes indicate that the request contains bad syntax or cannot be fulfilled.

Common Status Codes:

• 400 Bad Request: The server cannot process the request due to a client error (e.g., malformed request syntax).
• 401 Unauthorized: Authentication is required and has failed or has not yet been provided.
• 403 Forbidden: The client does not have access rights to the content.
• 404 Not Found: The server cannot find the requested resource.
• 405 Method Not Allowed: The request method is known by the server but is not supported by the target resource.
• 408 Request Timeout: The server timed out waiting for the request.
• 409 Conflict: The request could not be completed due to a conflict with the current state of the resource.
• 410 Gone: The resource requested is no longer available and will not be available again.
• 429 Too Many Requests: The user has sent too many requests in a given amount of time ("rate limiting").

---

5xx: Server Error

Description: The 5xx class indicates that the server failed to fulfill a valid request. The server is aware that it has encountered an error or is otherwise incapable of performing the request.

Common Status Codes:

• 500 Internal Server Error: A generic error message when the server encounters an unexpected condition.
• 501 Not Implemented: The server either does not recognize the request method or lacks the ability to fulfill it.
• 502 Bad Gateway: The server was acting as a gateway or proxy and received an invalid response from the upstream server.
• 503 Service Unavailable: The server is not ready to handle the request, often due to maintenance or overload.
• 504 Gateway Timeout: The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.
• 505 HTTP Version Not Supported: The server does not support the HTTP protocol version used in the request.

---

Understanding these status codes is essential for debugging web applications and ensuring efficient client-server communication. Each code provides specific information about what happened with a request, allowing developers to handle responses appropriately.

Original Context

Warning

Failed to run comment evaluation.

TypeError: Cannot read properties of undefined (reading 'wordValue')

Originally posted by @0x4007 in ubiquity/.github#115 (comment)

Similar ¹

Footnotes

1. Slow Start to Evaluation 75% ↩

[ubiquity-os]

Note

The following contributors may be suitable for this task:

0x4007

2% Match ubiquity/work.ubq.fi#125

rndquu

2% Match ubiquity/audit.ubq.fi#16
1% Match ubiquity/audit.ubq.fi#15

[0x4007]

@sshivaditya2019 ensure that the issue similarity searching is repo scoped. You can see beta keeps closing it because I transferred from another repo (presumably 100% match according to its database.) It should be attempting to link back to the original issue though, and it doesn't appear to be doing that. Be sure to handle that.

[Keyrxng]

I'm almost certain that this should only really require an update to ubiquibot-logger as it is responsible for the various error and comment diff wrapping.

The logger is not tied to comments but the logMessage.diff is what gives our comments colour. I'm unsure that renaming the current methods is a great idea tho.

If the intention is to make it clear when using the logger that this method is going to produce a Tip! comment then shouldn't we create new methods more inline with the comment style it produces as opposed to a http status? .redirect() doesn't line up with Important! Tip! doesn't go with .success(), our .fatal is the new 5xx CAUTION!.

Should the logger actually post the comment or just return the formatted string for the plugin to post?

[0x4007]

My original implementation had a post parameter do that

[Keyrxng]

My original implementation had a post parameter do that

I saw @gentlementlegen explained things in another comment just recently so I won't again here but what is to happen with my pr which has re-attached the posting capability for at least Supabase, should it also handle GitHub comment posting? The PR awaits review right now happy to make any other changes.

[0x4007]

Moved to ubiquity-os/ubiquity-os-logger#50