Change Velocity Issue

[Chandrashekar]

I have trying to create Change request in ServiceNow from GitHub, Change is created successfully but in Github it says Bad request missing input to process the request. if anyone know why we are facing this issue it will be really helpful #github  #changevelocity  #devops

[Vikram Reddy]

Hi @Chandrashekar,

That split, change record lands in ServiceNow but the GitHub Action step still fails with a "Bad request, missing input" is almost always the action-side call rejecting a payload, not a platform bug: the servicenow-devops-change action first creates the change (that part succeeds), then makes a follow-up call to track the change step/status against your workflow run, and that second call is what's choking on a missing or malformed input.

A few things worth checking on the workflow YAML side before you chase logs:

• job-name must be an exact, character-for-character match to the "name" of the job that contains this step, not the step name, not the workflow name. A mismatch here is the single most common cause of this exact "record created, action still errors" pattern.
• context-github has to be passed literally as ${{ toJSON(github) }}. If it's hardcoded, partially templated, or the JSON gets mangled by quoting, the action can't extract run id/job details and the downstream call comes back malformed.
• change-request JSON: if you're passing a custom payload here, validate it's actually valid JSON. A stray trailing comma or unescaped quote lets the minimum record still get created off the required fields, while the fuller payload call fails, which matches your symptom nicely.
• tool-id / SN_ORCHESTRATION_TOOL_ID: confirm it's the sys_id of the correct GitHub orchestration tool record in ServiceNow, not a stale or duplicate one.
• Make sure this step isn't running inside a job with parallel execution: the action explicitly doesn't support that, and it produces exactly this kind of inconsistent create-vs-report behavior.

On the ServiceNow side, pull up the actual change record and check the sn_devops_callback table (or Inbound Event processing) for the payload that came in around that timestamp: it'll usually show you which field the platform rejected, which is more reliable than reading the raw GitHub Action error text.

Thank you,
Vikram Karety
Octigo Solutions INC

[Chandrashekar]

Hello Vikram,
Thank you for your response

We validated all the points you suggested, and everything appears to be configured correctly.

If possible, could you please help me understand the end-to-end execution flow of this integration?

Based on my debugging, this is what I have understood so far:

• GitHub sends the request to the Inbound REST API (POST).
• The request is then handled by the Change Manager Script Include.
• From there, I can see that the Default Change Handler flow is invoked, which creates and populates the Change Request.
• A Step Execution record is also created.
• Once the Change Request is approved or rejected, the Callback Flow is triggered to send the status back to GitHub.

Is my understanding of the execution flow correct? If I've missed any intermediate steps or if the actual flow is different, could you please share the complete end-to-end process?

It would be very helpful in identifying where the issue is occurring. Thank you in advance for your help.

[Tanushree Maiti · Accepted solution]

Hi @Chandrashekar  

Refer Servicenow Documentation: Change request creation with DevOps data retrieval errors 

"

You can create a change request with or without errors in DevOps data retrieval. This functionality can be controlled by the Enable change request creation even with errors in DevOps data retrieval property. When the Enable change request creation even with errors in DevOps data retrieval property is enabled, and an error occurs in retrieving DevOps data like work items, commits, test summaries, or security summaries, the corresponding change request is still created. The data that can be retrieved will still be associated with the change request. For the data that can’t be retrieved, the reason for the error will be notified to the user in the third-party console, and the same information will also be added in the Change Comments field in the Step Execution record and the change Worknotes.

If the Enable change request creation even with errors in DevOps data retrieval property isn’t enabled, a change request is created only when there’s no error in any step of a pipeline run. When an error occurs, the pipeline is aborted and the reason for the error is added in the inbound event's Processing details field, and the same is notified to the user in the third-party console.

For more information, see DevOps Change Velocity properties."

[Chandrashekar]

Hello Thanushree,

Thanks for your response.

I checked the property you mentioned. It was set to false, so I changed it to true and tested the integration again. However, GitHub still receives the same "Bad Request" response.

Here's what we have observed:

• As soon as ServiceNow receives the request from GitHub, a Step Execution record is created with the state Pending Decision.
• Instead of waiting for the change approval or rejection, ServiceNow immediately sends a Bad Request response back to GitHub.
• Shortly after, the Step Execution state changes to Failed.
• Once the Change Request is approved, the Step Execution comments show: "devops.system does not have read access to the Step Execution table."
  
  

My understanding is that ServiceNow should wait for the Change Request to be approved or rejected before sending the callback response to GitHub. Is my understanding correct, or am I missing something in the expected behavior?