prisma / prisma-client-js

Type-safe database client for TypeScript & Node.js (ORM replacement)
Apache License 2.0
1.47k stars 67 forks source link

Generated Github issue creation links do often not include helpful information #865

Closed janpio closed 3 years ago

janpio commented 4 years ago

This repo reproduces a problem and causes 3 errors: https://github.com/divyendu-test/prisma-client-js-797

These are the links created automatically by Prisma Client for these errors: https://github.com/prisma/prisma-client-js/issues/862 https://github.com/prisma/prisma-client-js/issues/863 https://github.com/prisma/prisma-client-js/issues/864

On first look the "Logs" of these issues do not look very helpful. As we have a clear reproduction here, we can double check what would be helpful and possibly improve our logic that collects the information included in the issue.

Many more issues from real users can be found via https://github.com/prisma/prisma-client-js/labels/topic%3A%20basic%20reporting%20issue

pantharshit00 commented 4 years ago

A point of suggestion mentioned in https://github.com/prisma/prisma-client-js/issues/879

Please I'll appreciate it if this log can be dumped into a markdown file in the project root directory if the characters exceed the maximum URL allowed Thanks.

pantharshit00 commented 3 years ago

Here are few point of suggestion that I have which can improve the error reports a lot:

  1. Optionally ask the user to add the Prisma schema in the report via the prompt. A schema is always very helpful in triaging issues as schema is kind of the single source of truth for all Prisma tools right now. If we can get that in the error report(which explicit user consent), that will improve the reports a lot.

  2. Dump the whole error log into the reports. I personally feel this one might be a bug in the error reporting implementation. Right now most reports just dump this config object:

    prisma-client {
      engineConfig: {
        cwd: '/Users/divyendusingh/Documents/prisma/triage/prisma-client-js-797',
        enableDebugLogs: false,
        enableEngineDebugMode: undefined,
        datamodelPath: '/Users/divyendusingh/Documents/prisma/triage/prisma-client-js-797/node_modules/.prisma/client/schema.prisma',
        prismaPath: undefined,
        engineEndpoint: undefined,
        generator: {
          name: 'client',
          provider: 'prisma-client-js',
          output: '/Users/divyendusingh/Documents/prisma/triage/prisma-client-js-797/node_modules/@prisma/client',
          binaryTargets: [],
          previewFeatures: [],
          config: {}
        },
        showColors: false,
        logLevel: undefined,
        logQueries: undefined,
        flags: [],
        clientVersion: '2.6.0-dev.61',
        enableExperimental: [],
        useUds: undefined
      }
    }
    plusX Execution permissions of /Users/divyendusingh/Documents/prisma/triage/prisma-client-js-797/node_modules/.prisma/client/query-engine-darwin are fine
    plusX Execution permissions of /Users/divyendusingh/Documents/prisma/triage/prisma-client-js-797/node_modules/.prisma/client/query-engine-darwin are fine

    This is almost completely useless for me. Only thing that hints on the issue right now is the issue title, otherwise there are not much pointers for me.

  3. Include database information. This is already WIP for migrate and introspection error reporting but it would we also great if we can atleast include the database type so that I don't make assumption about it.

  4. Include engine binary hash This can be helpful in some cases.

  5. Ask user to add code snippets On the top of the generated issue template, we can also ask the user to include a code snippet if they know which part caused the crash.

Basically our end goal should be have generated issues close to our current manual issue template.