Firebase Realtime Database - Intermittently update() works like set() - node.js

Intermittently and unpredictably, the Firebase Realtime Database update() function seems to work like the set() function. Anecdotally, it appears to happen on about 1% of update operations. But we've performed extensive logging, and will see things happen like a particular update is being pushed out to a group of users inside of a loop, we verify that correct information is being sent to all of them in the logs, and update() is being called on each record. However, the outcome we'll see is that sometimes one of the users will wind up with a record that only contains the fields we updated, and all other fields in the record get deleted, while all other users receive the update properly. Running the exact same update() operation subsequently will result in everything updating as expected. Is this a known issue? Are there any workarounds? We are running firebase-admin 6.0.0 on Node 8.14.0
Attempted multiple repeated tests of the update() function. There is no surefire way to cause this issue to reproduce, but it is happening randomly in production.
const contactsRef = admin.database().ref().child('contacts');
...
//targetUID, contactID, contactObj get passed in via PubSub
...
contactsRef.child(targetUID).child(contactID).update(contactObj);
Expected: update() should only update the record fields being passed to it.
Actual: update() seems to work like set() randomly, about 1% of the time. Any fields that are not included in the object being passed to update() are deleted from the target record in the Realtime Database.

It seems very unlikely that the database server behaves differently for 1% of your users. Much more likely it that there is a slight difference in the calls that that 1% of your users makes. It's hard to be certain what that difference is from the code you shared, so below is an educated guess in hopes of unblocking you quickly.
You say you do:
contactsRef.child(targetUID).child(contactID).update(contactObj);
Expected: update() should only update the record fields being passed to it.
It's a bit subtle and unfortunately you don't show how you construct contactObj. So I'll give an example. Say that you start with JSON:
"uid1": {
"name": "unknown",
"id": -1,
"full_name": "unknown",
"metadata": {
"last_seen": "20 minutes ago",
"reputation" 56
}
}
And you run this on that location:
ref.update{
"name": "miles_b",
"id": 2687721
}
In this case only the name and id properties under ref are updated. The other properties are unmodified, so you end up with:
"uid1": {
"name": "miles_b",
"id": 2687721,
"full_name": "unknown",
"metadata": {
"last_seen": "20 minutes ago",
"reputation" 56
}
}
But now say that you also want to update the metadata/reputation. You might think that this works:
ref.update{
"name": "miles_b",
"id": 2687721,
"metadata": {
"reputation": 61
}
}
But here you are telling the database to replace metadata with the object you provided. So the result is:
"uid1": {
"name": "miles_b",
"id": 2687721,
"full_name": "unknown",
"metadata": {
"reputation" 61
}
}
And this means that last_seen is now gone from the database.
To update a nested property, include its full path in the key. So:
ref.update{
"name": "miles_b",
"id": 2687721,
"metadata/reputation": 61
}
And with that, you'll keep metadata/last_seen, while updating metadata/reputation:
"uid1": {
"name": "miles_b",
"id": 2687721,
"full_name": "unknown",
"metadata": {
"last_seen": "20 minutes ago",
"reputation" 61
}
}

Related

How to prevent entering duplicate data in Cosmos DB?

I have a container with id as partition key. Based on some condition, I do not want to enter duplicate data in my container, but I am not sure how to do that in Cosmos. i.e., I tried to create unique keys, but that didn't help me.
Condition:
Record will be duplicate if name + addresses[].city + addresses[].state + addresses[].zipCode are same.
Document:
{
"isActive": false,
"id": "d94d7350-8a5c-4300-b4e4-d4528627ffbe",
"name": "test name",
"addresses": [
{
"address1": "718 Old Greenville Rd",
"address2": "",
"city": "Montrose",
"state": "PA",
"zipCode": "18801",
"audit": {}
}
]
}
Findings:
Per https://stackoverflow.com/a/61317715, unique keys cannot include arrays. Unfortunately, I cannot change the document structure. So unique key approach is not the option.
Questions:
Do I need to change partition key? Not sure if I can have /id#name (or something like that) in Cosmos like Dynamo?
Is there any other way of handling this at DB level?
As a last resort, I can add the logic in my code to do this but that would be expensive in terms of RU/s.

Acumatica MoveEntry API not generating lot number

Has anyone here used the PUT /MoveEntry call successfully before? I can make the call to create the record, but I was expecting the API to populate the lot number and it is not. It does by UI, but not by API. Is there a trick that I'm missing?
Update 1:
PUT /MoveEntry
{
"Hold": {
"value": true
},
"Details": [
{
"OrderType": {
"value": "RO"
},
"ProductionNbr": {
"value": "RO0000001"
},
"Quantity": {
"value": 1
},
"Location": {
"value": "PRODRECPT"
},
"Warehouse": {
"value": "ABBOTSFORD"
}
}
]
}
It always records the document successfully, but never has the lot number.
Could it be a lot class configuration issue?
Update 2:
Acu support agrees this looks like a defect and has passed the case on to Acu development.
I would take a look at the Numbering Sequence called AMBatch as that is the one that seems to be used by default for me on the Move Entry screen.
After working with Acu Support, it came back the API requires the "OperationNbr" field to be populated with the Bill of Materials operation number. Then the lot number is generated as expected.

Forge-Get Item Path along with custom attributes in BIM360 document

Two Requirements are needed:
Get item path of the document in a BIM360 document management.
Get all custom attributes for that item.
For Req. 1, an api exists to fetch and for getting custom attributes, another api exists and data can be retrived.
Is there a way to get both the requirements in a single api call instead of using two.
In case of large number of records, api to retrieve item path is taking more than an hour for fetching 19000+ records and token gets expired though refesh token is used, while custom attribute api processes data in batches of 50, which completes it in 5 minutes only.
Please suggest.
Batch-Get Custom Attributes is for the additional attributes of Document Management specific. While path in project is a general information with Data Management.
The Data Management API provides some endpoints in a format of command, which can ask the backend to process the data for bunch of items.
https://forge.autodesk.com/en/docs/data/v2/reference/http/ListItems/
This command will retrieve metadata for up to 50 specified items one time. It also supports the flag includePathInProject, but the usage is tricky and API document does not indicate it. In the response, it will tell the pathInProject of these items. It may save more time than iteration.
{
"jsonapi": {
"version": "1.0"
},
"data": {
"type": "commands",
"attributes": {
"extension": {
"type": "commands:autodesk.core:ListItems",
"version": "1.0.0" ,
"data":{
"includePathInProject":true
}
}
},
"relationships": {
"resources": {
"data": [
{
"type": "items",
"id": "urn:adsk.wipprod:dm.lineage:vkLfPabPTealtEYoXU6m7w"
},
{
"type": "items",
"id": "urn:adsk.wipprod:dm.lineage:bcg7gqZ6RfG4BoipBe3VEQ"
}
]
}
}
}
}
Get item path of the document in a BIM360 document management.
Is this question about getting the hiarchy of the item? e.g. rootfolder>>subfolder>>item ? With the endpoint, by specifying the query param includePathInProject=true, it will return the relative path of the item (pathInProject) in the folder structure.
https://forge.autodesk.com/en/docs/data/v2/reference/http/projects-project_id-items-item_id-GET/
"data": {
"type": "items",
"id": "urn:adsk.wipprod:dm.lineage:xxx",
"attributes": {
"displayName": "my-issue-att.png",
"createTime": "2021-03-12T04:51:01.0000000Z",
"createUserId": "xxx",
"createUserName": "Xiaodong Liang",
"lastModifiedTime": "2021-03-12T04:51:02.0000000Z",
"lastModifiedUserId": "200902260532621",
"lastModifiedUserName": "Xiaodong Liang",
"hidden": false,
"reserved": false,
"extension": {
"type": "items:autodesk.bim360:File",
"version": "1.0",
"schema": {
"href": "https://developer.api.autodesk.com/schema/v1/versions/items:autodesk.bim360:File-1.0"
},
"data": {
"sourceFileName": "my-issue-att.png"
}
},
"pathInProject": "/Project Files"
}
or if you may iterate by the data of parent
"parent": {
"data": {
"type": "folders",
"id": "urn:adsk.wipprod:fs.folder:co.sdfedf8wef"
},
"links": {
"related": {
"href": "https://developer.api.autodesk.com/data/v1/projects/b.project.id.xyz/items/urn:adsk.wipprod:dm.lineage:hC6k4hndRWaeIVhIjvHu8w/parent"
}
}
},
Get all custom attributes for that item. For Req. 1, an api exists to fetch and for getting custom attributes, another api exists and data can be retrived. Is there a way to get both the requirements in a single api call instead of using two. In case of large number of records, api to retrieve item path is taking more than an hour for fetching 19000+ records and token gets expired though refesh token is used, while custom attribute api processes data in batches of 50, which completes it in 5 minutes only. Please suggest.*
Let me try to understand the question better. Firstly, two things: Custom Attributes Definitions, and Custom Attributes Values(with the documents). Could you clarify what are they with 19000+ records?
If Custom Attributes Definitions, the API to fetch them is
https://forge.autodesk.com/en/docs/bim360/v1/reference/http/document-management-custom-attribute-definitions-GET/
It supports to set limit of each call. i.e. the max limit of one call is 200, which means you can fetch 19000+ records by 95 times, while each time calling should be quick (with my experience < 10 seconds). Totally around 15 minutes, instead of more than 1 hour..
Or at your side, each call with 200 records will take much time?
If Custom Attributes Values, the API to fetch them is
https://forge.autodesk.com/en/docs/bim360/v1/reference/http/document-management-versionsbatch-get-POST/
as you know, 50 records each time. And it seems it is pretty quick at your side with 5 minutes only if fetch the values of 19000+ records?

Stripe Orders API tax callback

Trying to setup dynamic tax calcuation using Stripe Orders API. Using these docs:
https://stripe.com/docs/orders
https://stripe.com/docs/orders/dynamic-shipping-taxes
result = {
"order_update": {
"items": [
{
"parent": None,
"type": "tax",
"description": "Sales taxes",
"amount": 100,
"currency": "usd"
}
],
"shipping_methods": [
{
"id": "free_shipping",
"description": "Free 7-day shipping",
"amount": 0,
"currency": "usd",
"delivery_estimate": {
"type": "exact",
"date": "2020-08-11"
},
"tax_items": []
}
]
}
}
print(result)
return Response(result, status=status.HTTP_200_OK)
Even dummy response without any sophisticated computations failed to create an order object with HTTP 402 error for script trying to create Order
Creating order with no tax specified works as well and allows to create order.
Webservice running a callback receives a request from the Stripe as it must and works as well.
Stripe support says only "we no longer recommend developing your integration around this system" and does not answer directy if they turn off this feature.
If they turn off this feature I do not understand why it is available in the dashboard.
The issue was in the middleware of my service. It transformed response keys from snake_case to camelCase. Resolved.

Instagram API: .caption.created_time vs .created_time

What use case would create a difference between .caption.created_time and .created_time in the metadata objects from the JSON response? My app has been monitoring media recent data from the tags endpoint for about a week, collecting 50 data points, and those two properties have always been the exact same Epoch time. However, these properties are different in the example response in Instagram's docs, albeit the difference is only four seconds. Copied below:
"caption": {
"created_time": "1296703540",
"text": "#Snow",
"from": {
"username": "emohatch",
"id": "1242695"
},
"id": "26589964"
},
"created_time": "1296703536",
The user may have created the post with the original caption but then edited the caption and saved 4 seconds after they posted the original. Fix a typo, etc.

Resources