buggregator / server Goto Github PK

Like shoud looks like

XHProf URL: `http://localhost:3000/api/profiler/store`

          Ray integration in Laravel doesn't work in any recent releases: dev, lastest, rc

I am using docker and compose

docker-compose.yml

    buggregator:
      image: ghcr.io/buggregator/server:dev
      container_name: buggregator-${APP_HOST}
      ports:
        - 8000:8000
      networks:
        - docker-server

.env part

RAY_HOST=buggregator
RAY_PORT=8000

The ray() function works in the code, but the buggregator interface is empty, while Symphony var_dumper works fine!

There is an error in the browser console

Originally posted by @Semdevmaster in #24 (comment)

When viewing emails for mobile devices, the preview window does not fit within the height of the mobile device window. This causes the email to be cut off at the bottom, making it difficult or impossible to read the entire content of the email.

Sentry module not showing messages from Laravel
By classic artisan command for test: php artisan sentry:test get Error

In buggregator logs:

In browser console (Sentry tab and others)

The UI interface is empty

Buggregator server doesn't catch var-dumps in specific cases

For example, I installed temporal/samples-php project and
modified \Temporal\WorkerFactory (vendor package) like this:

    public function run(HostConnectionInterface $host = null): int
    {
        $host ??= RoadRunner::create();
        $this->codec = $this->createCodec();

        while ($msg = $host->waitBatch()) {
            try {
                \dump($msg->messages, $msg->context);
                $response = $this->dispatch($msg->messages, $msg->context);
                \dump($response); // line 263
                $host->send($response);
            } catch (\Throwable $e) {
                $host->error($e);
            }
        }

        return 0;
    }

After rr serve Buggregator Server doesn't catch responses. But buggregator/trap does.

Need to research the problem.

Hi there,

we are currently evaluation buggregator and were wondering if there are any plans to add support for mail attachments. It shows attachments under RAW and Headers, but there doesn't seem to be any way to download them yet?

Hi,

just wanted to install your amazing app, but the docs are not working - gives a 502.

Thanks for looking into it.

• Spiral Framework
• Laravel Framework
• Symfony

Hello,

I don't see the compatibility with Ray dump anymore, did you remove it?
Is it planned in a future version?

I seems that the buggregator displays only the first SMTP message and then shows the same one for another message that was send immediately after.

You can see in the image (sorry for the censorship) that first mail recipient is different from the second mail, yet bugregator shows the same. This extends to the email content too.

Also the timestamp on the detail doesn't work correctly. It's always showing current time instead of the time the email was sent, or rather received by bugregator

If I send not JSON then I see errors below in console.

2023-11-08T16:29:02.195Z ERROR   app             RuntimeException: Unable to decode a message from [0c3806ff-55f2-4219-92e8-b5795735060d] client. in /app/app/modules/Monolog/Interfaces/TCP/Service.php at line 36 [] []

I think we shoul write something like "Log message is not JSON!"

When the SEND_QUERIES_TO_RAY is set to true, it send queries to ray but buggregator not showing the query as in the image.

When click on JSON, the output contain executed query.

{
  "uuid": "5d703749-c3dd-43aa-b72e-27848efbef52",
  "type": "ray",
  "payload": {
    "uuid": "5d703749-c3dd-43aa-b72e-27848efbef52",
    "payloads": [
      {
        "type": "executed_query",
        "content": {
          "sql": "select * from \"users\" where \"id\" = 0 limit 1",
          "connection_name": "pgsql",
          "time": 20.12
        },
        "origin": {
          "file": "D:\\project_name\\vendor\\laravel\\framework\\src\\Illuminate\\Auth\\EloquentUserProvider.php",
          "line_number": 59,
          "hostname": "PC"
        }
      }
    ],
    "meta": {
      "php_version": "8.2.10",
      "php_version_id": 80210,
      "project_name": "project_name",
      "laravel_version": "10.28.0",
      "laravel_ray_package_version": "1.33.0.0",
      "ray_package_version": "1.39.0.0"
    },
    "peaks": {
      "wt": 0,
      "ct": 0,
      "mu": 0,
      "pmu": 0
    },
    "edges": []
  },
  "timestamp": 1698304850,
  "project_id": null
}

Is this expected or is a bug?

What more can I say? Whatever I send, I get a 404 and no result in the panel. How do I provide more details?

GET http://http-dump@localhost:8000/user/3/update

HTTP/1.1 404 Not Found
Server: nginx/1.20.2
Date: Sun, 03 Dec 2023 20:58:54 GMT
Content-Length: 0
Connection: keep-alive
Vary: Origin

<Response body is empty>

Response code: 404 (Not Found); Time: 2ms (2 ms); Content length: 0 bytes (0 B)

services:
    buggregator:
        image: ghcr.io/buggregator/server:latest
        pull_policy: always
        restart: always
        ports:
            - 127.0.0.1:8000:8000

Need to add possibility to batch delete events

Existed calls:
centrifuge.rpc("delete:api/events", undefined)
centrifuge.rpc("delete:api/events", {type})

Expected new call
centrifuge.rpc("delete:api/events", {uuids})

https://www.npmjs.com/package/html-to-image#toPng

• Introduction — Getting Started
• Networking overview — Published ports

Use the --publish or -p flag to make a port available to services outside of Docker. This creates a firewall rule in the host, mapping a container port to a port on the Docker host to the outside world.
Publishing container ports is insecure by default. Meaning, when you publish a container's ports it becomes available not only to the Docker host, but to the outside world as well.
If you include the localhost IP address (127.0.0.1) with the publish flag, only the Docker host can access the published container port.

services:
  # ...

  buggregator:
    image: ghcr.io/buggregator/server:dev
    ports:
      - 127.0.0.1:8000:8000
      - 127.0.0.1:1025:1025
      - 127.0.0.1:9912:9912
      - 127.0.0.1:9913:9913

We need to find an alternative to the current key-value (KV) storage system used in Bugregator for managing events and settings. One potential replacement is SurrealDB, an in-memory database. It's essential to investigate SurrealDB to determine its feasibility as a substitute for our existing KV storage solution. Relevant information can be found at https://github.com/surrealdb/surrealdb.

There is yiisoft/profiler. Probably we can add something for it?!

This feature request proposes the introduction of a functionality in Buggregator that allows users to respond to HTTP requests with customizable fake responses, based on schemas provided by the user. This would greatly enhance the testing and debugging capabilities of Buggregator.

Current Limitations

While Buggregator currently has the ability to catch HTTP requests and display comprehensive information (method, URI, payload, etc.), it lacks the feature to actively respond to these requests with predefined, user-customized fake responses.

Proposed Feature

1. Custom Response Creation: Allow users to define custom responses for intercepted HTTP requests. This includes the ability to specify the status code, headers, body, and delay time for the response.

2. Response Schema Definition: Enable users to create response schemas in json format.

3. Conditional Response Logic: Implement logic to match requests with appropriate fake responses based on criteria such as request method, URI, payload content, or headers.

Benefits

1. Enhanced Testing Capabilities: Developers can test client-side handling of various server responses without needing the backend to actually provide these responses.

2. Improved Debugging: This feature would allow developers to simulate server-side errors or delays to test how the front-end handles these scenarios.

3. Faster Development Cycle: By simulating backend responses, front-end development can proceed without waiting for backend implementation, leading to a more efficient development cycle.

4. User Experience Testing: It enables testing of different user experience flows based on various server responses, improving the robustness of the application.

Use cases

1. Front-end Development: Front-end developers can simulate backend responses to test UI components and error handling mechanisms.

2. API Testing: Test how your application responds to unexpected or error responses from a server.

Draft JSON schema for response definition

{
   "title":"User Creation Schema",
   "match":{
	   "url": "user/store",
	   "method": "POST",
	   "headers": [
	          {"X-Response-Type": "success"}
	   ],
   },
   "response": {
	   "statusCode": 200,
	   "headers": [
	          {"Foo": "Bar"}
	   ],
	   "cookies": [
	          {"Foo": "Bar"}
	   ],
	   "serverAttributes": [
	          {"Foo": "Bar"}
	   ],
	   "properties":{
	      "username":{
	         "type":"string",
	         "provider":"userName",
	         "description":"User's chosen username."
	      },
	      "email":{
	         "type":"string",
	         "format":"email",
	         "provider":"email",
	         "description":"User's email address."
	      },
	      "password":{
	         "type":"string",
	         "provider":"password",
	         "description":"User's chosen password."
	      },
	      "fullName":{
	         "type":"string",
	         "provider":"name",
	         "description":"User's full name."
	      },
	      "userId":{
	         "type":"integer",
	         "provider":"randomNumber(1, 100)",
	         "description":"User's ID."
	      },
	      "status":{
	         "type":"string",
	         "provider":"randomElement(['new', 'success', 'failed'])",
	         "description":"User's status."
	      },
	      "address":{
	         "type":"object",
	         "properties":{
	            "street":{
	               "type":"string",
	               "provider":"streetAddress"
	            },
	            "city":{
	               "type":"string",
	               "provider":"city"
	            },
	            "state":{
	               "type":"string",
	               "provider":"state"
	            },
	            "zipCode":{
	               "type":"string",
	               "provider":"postcode"
	            }
	         }
	      },
	      "phoneNumber":{
	         "type":"string",
	         "provider":"phoneNumber",
	         "description":"User's phone number"
	      }
	   },
   }
}

In this schema, each property includes a provider field that specifies the FakerPHP method used to generate the mock data for that field. This setup is particularly helpful for automated testing or when populating a database with mock data for development purposes.

The match object indicates that both url and method are mandatory for the matching process, ensuring that the response is linked to a specific type of request. This setup is useful for mock servers or testing environments where you need to simulate responses based on different request scenarios.

When we build a docker image instead of download centrifugo binary we need to ge binary from docker image https://hub.docker.com/r/centrifugo/centrifugo

Hi. There seems to be problem with boolean dumps to the dump server. True is displaying as false and false is displaying as true. For example, this is the Buggregator JSON:

And this is what's displayed:

Make button Clear events always visible on the page:

This feature greatly aids in clearing contents without the need for scrolling back to the top.

https://usehelo.com/

• Broken Link Checker

Maybe something else?

The aim of this proposal is to introduce webhook functionality to Buggregator, enabling external notifications for various event types received by the system. This feature will allow users to configure webhooks via YAML files that define actions triggered by specific events. The proposed YAML structure for each webhook is as follows:

webhook:
  uuid: 018f0c52-7b8b-717a-9f43-210fd48d8552
  event: sentry.received
  url: https://webhook.site/507341b8-83de-40c4-8d88-cdaf0dea3047
  headers:
    X-Auth: secret
  verify_ssl: false
  retry_on_failure: true

Types of Events:

Buggregator can currently handle the following events:

• sentry
• monolog
• var-dumper
• ray
• inspector
• http-dump
• profiler
• smtp

Docker Configuration:

Webhook configurations can be mounted into the Buggregator Docker container using the following volume configuration:

buggregator-server:
  ...
  volumes:
    - ./webhooks:/app/runtime/webhooks

This setup allows for easy management and updating of webhook configurations without needing to rebuild or restart the entire container.

Execution Strategy:

Each webhook will be triggered in a separate process using the RoadRunner in-memory queue driver. This approach ensures that the main application performance is not hindered by the webhook processing tasks.

Configuration Options:

There are two main approaches to consider for managing webhook configurations within the Buggregator Docker container:

1. Single File Configuration:

   • Pros:
     • Centralized management of all webhooks, making it easier to oversee and audit.
   • Cons:
     • A single point of failure; corruption or misconfiguration in this file could disable all webhook integrations.
     • Larger file might become unwieldy as the number of webhooks grows.

2. Multiple Files Configuration (each webhook in a separate file):

   • Pros:
     • Isolates configurations, minimizing the risk where an error in one file affects others.
     • Easier to manage lifecycle of individual webhooks (create, delete, update) without affecting others.
   • Cons:
     • Could be harder to get an overview of all configured webhooks at a glance without additional tooling.

Retry Mechanism:

The retry_on_failure option is designed to attempt delivering the webhook notification up to 3 times in case of failures such as network errors, response timeouts, or server errors from the webhook URL.

Rationale for n8n Integration:

Integrating with n8n opens a multitude of possibilities for automating responses to events within Buggregator:

• Automated Alerting: Trigger emails, SMS, or chat messages based on certain event thresholds or error types.
• Issue Resolution Workflows: Automatically create tickets in project management tools like Jira or GitHub Issues when specific types of errors are reported.
• Custom Integrations: Enable custom workflows that can interact with virtually any API-driven service, providing flexibility to tailor responses specifically to the needs of your infrastructure.

I use script below for testing. As you see it sends 100 messages. But in buggregator I can see only few.

# socket_handler.php

use Monolog\Formatter\JsonFormatter;
use Monolog\Handler\SocketHandler;

$monolog = new \Monolog\Logger('logger');

$handler = new SocketHandler(
    connectionString: 'tcp://buggregator:9913',
);
$handler->setFormatter(new JsonFormatter(JsonFormatter::BATCH_MODE_NEWLINES));
$monolog->pushHandler($handler);


for ($i = 0; $i <= 100; $i++) {
    $monolog->info("message $i");
    usleep(1_000);
}

 php ./sandbox/socket_handler.php 

Fatal error: Uncaught RuntimeException: End-of-file reached, probably we got disconnected (sent 0 of 145) in /srv/vendor/monolog/monolog/src/Monolog/Handler/SocketHandler.php:420
Stack trace:
#0 /srv/vendor/monolog/monolog/src/Monolog/Handler/SocketHandler.php(99): Monolog\Handler\SocketHandler->writeToSocket('{"message":"mes...')
...

It looks like the bugggregator (rr) is closing the socket for unknown reasons.

Buggregator can check a new version in the Settings page and notify a user.

Something like this

Buggregator has an API, but there's no easy way for developers to see how it works. This makes it tough for them to use it properly.

We should add Swagger documentation for our API. This will help everyone understand how to use it.

With Swagger:

1. Developers can see and try out all the API parts.
2. It's easier for other apps to work with Buggregator.

Hi guys

It seems Inspector isn't working in Laravel. Sending to inspector.dev works correctly but not sending to Buggregator. I'm using the latest v1.0.0 Docker image.

The docs say this should be the config:

INSPECTOR_URL=http://[email protected]:8000
INSPECTOR_API_KEY=test
INSPECTOR_INGESTION_KEY=1test
INSPECTOR_ENABLE=true

But this line in the Inspector EventHandler suggests the uri should end with inspector?

I tried the above config and the following two configs with no luck:

INSPECTOR_URL=http://127.0.0.1:8000/api/inspector
INSPECTOR_API_KEY=test
INSPECTOR_INGESTION_KEY=1test
INSPECTOR_ENABLE=true

INSPECTOR_URL=http://127.0.0.1:8000/inspector
INSPECTOR_API_KEY=test
INSPECTOR_INGESTION_KEY=1test
INSPECTOR_ENABLE=true

Any ideas?

Thanks again!

The latest Docker image of the Buggregator server is incompatible with arm64 machines.

Steps to reproduce

• Get an arm64 machine (I am testing this on a cax11 server at Hetzner).
• Install Docker.
• docker pull ghcr.io/buggregator/server:latest
• docker run ghcr.io/buggregator/server:latest

exec /usr/local/bin/docker-php-entrypoint: exec format error

Additional information

Docker inspect shows the correct arm64 architecture for the image. I did some digging and found the issue is not with the Buggregator server directly, but with the images from the repositories the server depends on.

ghcr.io/buggregator/frontend:latest gives me "Architecture": "amd64".
ghcr.io/buggregator/docker:latest also gives me "Architecture": "amd64".

Workaround

For now, I cloned the Buggregator server, docker, and frontend repositories. Then, I built my own arm64 images for frontend and docker, pushed them to ghcr.io, and edited the Dockerfile of the Buggregator server to use my images.

I built an arm64 image of the server and pushed that to ghcr.io as well.

I made the final image of the server public in case someone else needs it for now.

docker pull ghcr.io/maantje/buggregator:latest

We just came across the same problem, but in our case it is a react app that sends sentry issues directly via browser. Initially we got a 404 because the Sentry API eventhandler didn't find the necessary headers. After faking the headers we got the above error (obviously).

It would be awesome if buggregator could support Sentry events from JavaScript SDKs. :)

Originally posted by @eXaminator in #18 (comment)

I like UI from this project https://github.com/AhmadWaleed/laravel-blanket

Sometimes I need to check how certain code would work in PHP. But I don't want to put this code in a file in my data for this purpose, I don't have the Tinkerwell application (for economic and ideological reasons) and I don't want to upload my confidential data to 3v4l.org. It would be nice if you added support for some REPL (e.g. PsySH) to the UI in such a way that it would send commands to the REPL and display the responses. And the user could connect any number of containers with different versions of PHP to test cases. This solution appears to be a Tinkerwell clone, but it is not. What I mean here is a pure approach of accessing the REPL without installing anything in the application (maybe just a client script somewhere in a container, depending on the solution). So that we have this REPL in the UI, but with minimal interference to the environment and design in the PHP container.

Config

SENTRY_DSN=http://sentry@buggregator:8000/1
VAR_DUMPER_FORMAT=server
VAR_DUMPER_SERVER=buggregator:9912
MONOLOG_SOCKET_HOST=buggregator:9913
MAILER_DSN=smtp://buggregator:1025

VarDumper, Monolog and SMTP modules working properly. I checked the hosts from the container - they are reachable.

Packages

Code

I put a dump here to find out why communication is not working

\Sentry\Transport\HttpTransport::send

        try {
            /** @var ResponseInterface $response */
            $response = $this->httpClient->sendAsyncRequest($request)->wait();
        } catch (\Throwable $exception) {
            dump($exception);

            $this->logger->error(
                sprintf('Failed to send the event to Sentry. Reason: "%s".', $exception->getMessage()),
                ['exception' => $exception, 'event' => $event]
            );

            return new RejectedPromise(new Response(ResponseStatus::failed(), $event));
        }

Exception

Http\Client\Common\Exception\ServerErrorException {#6139 ▼
  #message: "Internal Server Error"
  #code: 500
  #file: "/var/www/html/vendor/php-http/client-common/src/Plugin/ErrorPlugin.php"
  #line: 87
  -request: GuzzleHttp\Psr7\Request {[#6120 ▼]
    -method: "POST"
    -requestTarget: null
    -uri: GuzzleHttp\Psr7\Uri {#6115 ▶}
    -headers: array:4 [▼
      "Host" => array:1 [▼
        0 => "buggregator:8000"
      ]
      "Content-Type" => array:1 [▼
        0 => "application/x-sentry-envelope"
      ]
      "User-Agent" => array:1 [▼
        0 => "sentry.php.symfony/4.12.0"
      ]
      "X-Sentry-Auth" => array:1 [▼
        0 => "Sentry sentry_version=7, sentry_client=sentry.php.symfony/4.12.0, sentry_key=sentry"
      ]
    ]
    -headerNames: array:4 [▶]
    -protocol: "1.1"
    -stream: GuzzleHttp\Psr7\Stream {#6119 ▶}
  }
  #response: GuzzleHttp\Psr7\Response {[#6064 ▼]
    -reasonPhrase: "Internal Server Error"
    -statusCode: 500
    -headers: array:10 [▶]
    -headerNames: array:10 [▶]
    -protocol: "1.1"
    -stream: GuzzleHttp\Psr7\Stream {#6113 ▼
      -stream: stream resource @1608 ▶}
      -size: null
      -seekable: true
      -readable: true
      -writable: false
      -uri: "Symfony-Component-HttpClient-Response-StreamWrapper://http://buggregator:8000/api/1/envelope/"
      -customMetadata: []
    }
  }
  trace: {▶}
}

I am not sure what is going on since my first buggregator service in a different docker compose works fine, but this one is failing to start. The exposed ports are different.

buggregator  | handle_serve_command: Serve error:
buggregator  |   endure_start:
buggregator  |   endure_serve_internal: Function call error:
buggregator  |   endure_call_serve_fn: got initial serve error from the Vertex tcp.Plugin, stopping execution, error: static_pool_allocate_workers: WorkerAllocate: EOF

version: "3.8"

networks:
  my-network:
    driver: bridge

services:
  buggregator:
    stop_grace_period: 1s
    stop_signal: SIGKILL
    image: ghcr.io/buggregator/server:latest
    networks:
      - my-network
    ports:
      - "8065:8000"

Thanks to @js361014 we have an ability to send events into a specific project, but at this moment Buggregator supports projects only for Sentry module, other modules will use default project.

For SMTP module we can use username for specifying project

MAIL_USERNAME={projectId}

For inspector module we can can pass projectId in uri

INSPECTOR_URL=http://{projectId}@127.0.0.1:23517/inspector

For Ray module we can can pass projectId in uri

RAY_HOST={projectId}@127.0.0.1

For Monolof module we can can pass projectId in uri only for slack log channel

LOG_SLACK_WEBHOOK_URL=http://{projectId}127.0.0.1:23517/slack

One of the services in our stack submits a sentry event without gz-compression, but since it is not a service from our end, we can't simply enable the gz-compression.
Version is latest dev.
I guess it should work without gz-compression, since this is plain http?

2023-02-13T11:19:16.732Z	ERROR	app         	ErrorException: fwrite(): zlib: data error in /app/vendor/clue/stream-filter/src/functions.php at line 280 [] []

While Buggregator provides excellent support for debugging local PHP applications, there is currently no native support for debugging remote applications. This limitation requires developers to rely on alternative solutions, or possibly bypass Buggregator altogether when working with remote environments.

I propose adding support for SSH port forwarding in Buggregator. This would allow developers to establish an SSH tunnel from their local machine to a remote server, effectively mapping a local port to a port on the remote server. This would facilitate real-time debugging of applications deployed on remote environments as if they were local.

Key Features:

1. SSH Connection Management: An interface within Buggregator to save, manage, and quickly connect to remote servers using SSH credentials.
2. Real-time Debugging: Seamless integration of the debugging process, whether the application is local or remote.
3. Intuitive UI/UX: A straightforward UI to set up and manage remote debugging sessions without the need for external tools or complicated command lines.

Information can get from here https://www.ssh.com/academy/ssh/tunneling/example

Hello,
is it possible to combine the xhrof viewer with laravel?