Why is the Azure Devops API telling me that I must have these parameters for my Push request when I already do? - ado

I'm trying to make a Git push request to our Azure Devops server via the API. The address is https://MYSITE.visualstudio.com/MYPROJECT/_apis/git/repositories/2b34d4f7-2c1f-42e7-8861-u0ba34f72b40/pushes?api-version=5.1 and the body is as follows:
{
"commits": [
{
"comment": "Just a dummy commit",
"changes": [
{
"changeType": "edit",
"item": {
"path": "/src/MYPROJECT/MYPROJECT.csproj"
},
"newContent": {
"content": "beans",
"contentType": "rawText"
}
}
]
}
],
"refUpdates": [
{
"name": "refs/heads/TestDummyPRs/upgradeProjectToLatest",
"oldObjectId": "058da4f3328cb1048cb43faf3b5158bc3b025615"
}
]
}
I'm getting the following error:
Web Request Failed after 4 attempts. Request: https://MYSITE.visualstudio.com/MYPROJECT/_apis/git/repositories/2b34d4f7-2c1f-42e7-8861-u0ba34f72b40/pushes?api-version=5.1. Status: BadRequest. Response: Invalid status code [BadRequest]. Response: {"$id":"1","innerException":null,"message":"The parameters are incorrect. A posted push must contain exactly one commit and one refUpdate.\r\nParameter name: newPush","typeName":"Microsoft.TeamFoundation.SourceControl.WebServer.InvalidArgumentValueException, Microsoft.TeamFoundation.SourceControl.WebServer","typeKey":"InvalidArgumentValueException","errorCode":0,"eventId":0}
"A posted push must contain exactly one commit and one refUpdate" doesn't seem entirely reasonable as that's exactly what I have in my body. Does anybody know what might be going on here?
Note that I am having no issues making other web requests, such as creating branches or retrieving file contents.
I expected my web request to proceed smoothly, and to create a Push containing the specified commit to the specified refUpdate.
I have made a manual push for via the Azure Devops web interface and caught the network traffic, and I grabbed the following JSON request out of it:
{
"commits": [
{
"changes": [
{
"changeType": 2,
"item": {
"path": "/src/MYPROJECT/MYPROJECT.csproj"
},
"newContent": {
"content": "beans",
"contentType": 0
}
}
],
"comment": "Just a dummy commit"
}
],
"refUpdates": [
{
"name": ""refs/heads/TestDummyPRs/upgradeProjectToLatest",
"oldObjectId": "058da4f3328cb1048cb43faf3b5158bc3b025615"
}
]
}
This seems to be meaningfully identical to the Push I'm making from my code, other than the enum fields using numerical values instead of text. I have tried my code with numerical values for enums, but that didn't change anything about the error.

I found the issue. The web request from my application was being sent with UTF-16 encoding, whereas Postman had defaulted to UTF-8 encoding. I changed my application to use UTF-8 and it worked.

Related

Twilio Autopilot SMS not accepting media image type

I wrote a task a while back that would run a collect flow and collect an image using the model on the docs for doing so (https://www.twilio.com/docs/autopilot/actions/collect#questions). It ran flawlessly, and I tested it to make sure it ran as expected.
I made a new account using the company email to migrate my work over, and continue implementing the code, and eventually reached the portion where I needed to integrate that media collection. I used the same code, but it didn't work. The collect flow keeps on triggering the validate portion and telling me that it isn't an accepted type. I have tried it using the exact code from before as well as the exact image, but it still isn't working. The only thing I can think of is if the phone number was set up differently somehow. The message logs show the image as sent and looks fine and I can't find any differences other than that.
Is there anything that might be causing this? Here is the code for reference
{
"actions": [
{
"collect": {
"name": "image_collect",
"questions": [
{
"question": "Please upload an image",
"name": "image",
"type": "Twilio.MEDIA",
"validate": {
"on_failure": {
"messages": [
{
"say": "We do not accept this format. Please send another image."
}
]
},
"allowed_types": {
"list": [
"image/jpeg",
"image/gif",
"image/png",
"image/bmp",
"application/pdf"
]
}
}
}
],
"on_complete": {
"redirect": "https://4894-100-33-3-193.ngrok.io/image_processing"
}
}
}
]
}
Generally, media size causes this issue, just make sure the file size is within the limits.
For more info - https://www.twilio.com/docs/sms/accepted-mime-types

Issue passing in custom parameters to Twilio API

I am attempting to build out a process that will do the following:
New contact lands in my CRM (Podio)
The CRM is triggered to send a POST containing a custom parameter to Twilio which will then initiate a flow
The Twilio flow will call my cell and prompt me to connect to the new contact
Once I press 1, it will take the custom parameter (new contact's phone number) and connect
me to them.
So far, I have been able to get 1-3 with no problem.
However, according to the the API documentation from Twilio I should be able to pass a 3rd parameter in the JSON body of my HTTP request containing custom "Parameters". When I attempt this the parameters aren't showing in the Twilio studio logs and thus I am unable to connect the call to the new lead.
This is the JSON body I am sending over to my Twilio Flow's API
{
"To": "+1xxxxxxxxx1",
"From": "+1xxxxxxxxx2",
"Parameters": {
"name": "example name",
"prospectphone": "+1xxxxxxxxx3"
}
}
When I view the logs in Twilio this is what I received.
{
"contact": {
"channel": {
"address": "+1xxxxxxxxx2"
}
},
"trigger": {
"request": {
"from": "+1xxxxxxxxx2",
"to": "+1xxxxxxxxx1",
"parameters": {}
}
},
"widgets": {},
"flow": {
"flow_sid": "FW936f72c0eb8d3945d0d55c62465e37a8",
"data": {},
"channel": {
"address": "+1xxxxxxxxx2"
},
"sid": "FN955cdb12827f84c8af8fc9b5264e5a28"
}
}
I really can't figure out what I'm missing here? Has anyone run into this before? Is this something you can only do if you're using the SDK or does the additional parameter need to be passed in some other way?
It should be sent x-www-form-urlencoded.
From the documentation:
"Note: the JSON value must explicitly be passed as a string, not as a hash object. Depending on your particular HTTP library, you may need to add quotes or URL encode the JSON string."
Trigger a Twilio Studio Flow Execution via the REST API

Azure Logic App returns 404 with valid Project Online ODATA query using /_api/Projectdata

I want to filter and select Project Online data using Enterprise Custom Fields (ECF) in an Azure Logic App. I start with the out-of-the-box Project Online connector to trigger on project publish, then list project and task details.
Using the default connector, I can return project data but it does not contain the ECF data. Looking at the generated code, the Project Online connector uses /_api/ProjectServer. If I make similar requests (outside of Logic Apps) using /_api/Projectdata I get the ECF data.
If I edit the Logic App code with modified URL and fields, I get a 404 error. There seems to be something missing that I cannot see when I make the request with the modified values from within the Logic App.
My guess is the connector is limiting access to /_api/Projectdata (though the trigger itself is using this URL).
The following returns the data I want if I request it straight from the browser:
https://tenant.sharepoint.com/sites/PWA/_api/Projectdata/Projects(guid'project_GUID')
This is the raw input in the logic app:
{
"host": {
"connection": {
"name": "/subscriptions/subscription_GUID/resourceGroups/MyRG/providers/Microsoft.Web/connections/projectonline-1"
}
},
"method": "get",
"path": "/_api/Projectdata/Projects(guid'project_GUID')",
"queries": {
"siteUrl": "https://tenant.sharepoint.com/sites/PWA"
}
}
This is the raw output of the error:
{
"statusCode": 404,
"headers": {
"Access-Control-Allow-Methods": "GET, PUT, PATCH, DELETE, POST",
"Access-Control-Allow-Origin": "*",
"Access-Control-Max-Age": "3600",
"Access-Control-Expose-Headers": "*",
"Date": "Thu, 20 Sep 2018 16:58:42 GMT",
"Content-Length": "54",
"Content-Type": "application/json"
},
"body": {
"statusCode": 404,
"message": "Resource not found"
}
}
URLs and GUID have been modified in the examples above.

Two identical metadata requests, first one returns status 200, the 2nd one 404

Below you will find 2 metadata requests to the same OData Service. Except the cookie digit stream, they look like 2 drops of water, completely identical.
First one is triggered via the manifest.json file and its result is successful. Copied the data source definition to the manifest.json file of a second different application and put at work the debugger, expecting the same successful result.
"dataSources": { "mainService": { "uri": "/Uni_Sandpit_Virtual/sap/opu/odata/SAP/ZCONTRACTS_SRV/", "type": "OData", "settings": { "odataVersion": "2.0" } } },
To my absolute surprise the second metadata call returns 404 (not found). What do I miss here?
Best regards,
Greg
Request returning status 200
Request returning status 404
​Found the issue, posting it in case some other runs on the same problem.
Missing "path" block inside the neo-app.json file:
{ "path": "/Uni_Sandpit_Virtual", "target": { "type": "destination", "name": "Uni_Sandpit_Virtual" },

TFS 2015U3 build REST api specify reuqired demands

I'm trying to use the TFS rest API to trigger various builds. Each build that gets triggered, requires different demands.
E.g. I tried something like:
{
"definition": {
"id": 190
},
"sourceBranch": "refs/heads/master",
"demands":{"XXXXXXX":""},
This build executes fine, although no Agent satisfies the demand. Also various variations didn't work as expected.
In the documentation https://www.visualstudio.com/en-us/docs/integrate/api/build/overview I was not able to find anything regarding demands.
How does the body need to look like, so that the demands work?
After inspecting my http traffic with fiddler I finally found out what the body needs to be to send demands:
$body = #"
{
"definition": {
"id": 190
},
"sourceBranch": "refs/heads/master",
"parameters": "{\"configuration\":\"Debug\"}",
"demands":["xxxxxxxxxxxxxxxxx","yyyyyyyyyyy -equals zzzzzzzzzzzzz"],
}
"#

Resources