Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Long commit message causes postgres insert error #914

Closed
logan opened this issue Mar 12, 2015 · 4 comments
Closed

Long commit message causes postgres insert error #914

logan opened this issue Mar 12, 2015 · 4 comments

Comments

@logan
Copy link

logan commented Mar 12, 2015

The postgres schema for commits uses VARCHAR(255) for the message. If the commit message exceeds this length, then an error occurs trying to commit the commit to the DB.

By the way, the error handling in the hook handler leaves a lot to be desired. A lot of these 400s really should be 500s, and all of them discard the error string instead of logging or returning it, leaving us guessing as to the cause.

@bradrydzewski bradrydzewski modified the milestone: v0.4.0 Aug 18, 2015
@bradrydzewski bradrydzewski changed the title Long commit message causes webhook handler to return 400 Long commit message causes postgres insert error Aug 18, 2015
@bradrydzewski bradrydzewski modified the milestones: v0.4.1, v0.4.0 Aug 22, 2015
@bradrydzewski bradrydzewski modified the milestones: Unplanned, v0.4.1 Jul 11, 2016
@tboerger
Copy link

@bradrydzewski bradrydzewski removed this from the Unplanned milestone May 13, 2017
bradrydzewski added a commit that referenced this issue May 14, 2017
@thomasf
Copy link

thomasf commented May 15, 2017

Always use text fields to represent text, varchar should only be used to validate text types which has a known maximum length.
Looking at the migration sql files it seems that many varchar columns which probably should be text

@bradrydzewski
Copy link

I think putting limits on column size is a good thing. We don't want to accept a hook with a 1GB commit message for example.

@thomasf
Copy link

thomasf commented May 15, 2017

The kind of validation you are talking about now should probably be done before parsing a request using maximum "request" size check while or before reading..

I guess having the database do some checks as well isn't too bad, I see that you also truncate the message if it's too long..

You could easily multiply your current limits by 100 and still be relatively safe though.

bot2-harness pushed a commit that referenced this issue Dec 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants