Skip to content
This repository has been archived by the owner on Oct 2, 2018. It is now read-only.

prevented grimServerID from being over 15 chars #62

Merged
merged 1 commit into from
Jun 16, 2015

Conversation

harisgodil-MM
Copy link
Contributor

Truncates the grimServerID and logs that it was truncated and how to fix it

grimServerID := config.grimServerID
if len(grimServerID) > 15 {
grimServerID = fmt.Sprintf("%s", grimServerID[:15])
logger.Printf("grimServerID shouldn't be over 15 characters and has been truncated\nPlease update your config.json file to have a shorter grimServerID\n")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

grimServerID is the name of the in memory field. In the config it is actually GrimServerID. Also, note it is possible to get the GrimServerID set by the "defaults" which is hte grim queue name, so they might not even have a GrimServerID. Don't know what to do about that, maybe add to the error message?

Also note, you haven't truncated the grimServerID globally, only for the first message. So the next time they do a notify (like 3 lines later) it will trigger again.

So, you should move this code to the config file validation/load code. That will cause it to trigger on startup, not on the first notify message.

return err
}

err = sendMessageToRoom(config.hipChatToken, config.hipChatRoom, config.grimServerID, message, color)
grimServerID := config.grimServerID
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

grimServerID is the name of the in memory field. In the config it is actually GrimServerID. Also, note it is possible to get the GrimServerID set by the "defaults" which is hte grim queue name, so they might not even have a GrimServerID. Don't know what to do about that, maybe add to the error message?

Also note, you haven't truncated the grimServerID globally, only for the first message. So the next time they do a notify (like 3 lines later) it will trigger again.

So, you should move this code to the config file validation/load code. That will cause it to trigger on startup, not on the first notify message.

@@ -19,6 +19,7 @@ var (
defaultResultRoot = "/var/log/grim"
defaultWorkspaceRoot = "/var/tmp/grim"
configFileName = "config.json"
truncatedGrimServerID = ""
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You never use this (and you shouldn't as it is a global variable).

@kklipsch
Copy link
Contributor

What you've done is:

  1. created a global variable.
  2. Set it on startup.

But it isn't actually being used anywhere. So the hipchat notification will still see and use the longer than 15 character name.

What you should do:

  1. Validate/truncate in the loading of the config file https://github.com/MediaMath/grim/blob/master/config.go#L150
  2. Log that you've done this truncation. This will require adding either a logger injected into that function (which may be painful) or a special error that you return with that function and look at to determine if it is an "ok" error (which may be dangerous).

One option might be to add a field to the effective config struct that is "hipchatGrimServerId" and do the truncation into that struct. Then for logging on startup right after loading you can check to see if grimServerID != hipchatGrimServerId and log in that case.

Then in the notify function you should use the truncated value.

@harisgodil-MM
Copy link
Contributor Author

I made a slight change to the implementation from what @kklipsch said I should do
Rather than put the truncated value into hipchatGrimServerID and have the grimServerID be unmodified, I put the truncated value into grimServerID and the original to origServerID. This way grimServerID would be used the same way it was before

var buf bytes.Buffer
logger := log.New(&buf, "", log.Lshortfile)

tempDir, _ := ioutil.TempDir("", "TestTruncatedGrimServerID")

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no err ?

return effectiveConfig{
grimQueueName: firstNonEmptyStringPtr(global.GrimQueueName, &defaultGrimQueueName),
resultRoot: firstNonEmptyStringPtr(global.ResultRoot, &defaultResultRoot),
workspaceRoot: firstNonEmptyStringPtr(global.WorkspaceRoot, &defaultWorkspaceRoot),
grimServerID: firstNonEmptyStringPtr(global.GrimServerID, global.GrimQueueName, &defaultGrimQueueName),
grimServerID: truncatedServerID,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My own personal preference is to leave the config as it was created by the user. And to store the truncated in a new value. That way there is no confusion about what the user entered.

That said it is a nitpick and you don't have to change it.

@harisgodil-MM
Copy link
Contributor Author

Logger now knows which parameter in the config.json file was too large (GrimServerID and GrimQueueName) and uses it in the logged message
With that, the message became too complex to be stored as a global variable, so i made a method to create the message

@@ -218,3 +222,9 @@ func (i *Instance) checkGrimQueue() error {

return nil
}

func BuildTruncatedMessage(truncateID string) string {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function doesnt need to be exported. If it is exported it needs to be commented. golint would tell you this so I suspect you are not running golint? (make check will do this for you)

truncateID = "GrimQueueName"
}
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally I think I'd like to see this pulled out into a function called performCorrections (or something to that effect) that takes an effectiveConfig and returns (effectiveConfig, []error). That way the caller has the before/after and the messages that it can log or throw away.

Don't worry about it unless @kklipsch agrees though. This implementation is solid as is.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whenever we get an effectiveConfig, we are reading it from the file. If we go with this approach, we would have to call performCorrections every time we use an effectiveConfig.

kklipsch added a commit that referenced this pull request Jun 16, 2015
prevented grimServerID from being over 15 chars
@kklipsch kklipsch merged commit 835c154 into MediaMath:master Jun 16, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants