Client company just upgraded to 2016 from 2011. I've been testing the plugins to make sure they all still function and I've finally (after much frustration) figured out what is happening, but no idea why or how to resolve this.
I have several plugins and they all function exactly as expected - as long as the updates to the data are not run through the forms.
Let me explain:
I have plugins (Synchronous) that trigger on a change to a field. If the field is changed via a workflow, or some other coded process, everything runs just fine.
But when I update the field on the form it's self. It fails with a very generic error (below).
I support a couple of other clients already on 2016, and I'm not experiencing this same problem. So I'm not even sure where to begin. I've been going crazy here the last couple of days to check the code. But it only happens when updating the field on the form. Every other method of updating the data that I have tested works with no errors.
I also have another issue. When the field is updated (through a test workflow), it runs and updates a child record. The child record then has a workflow that runs to deactivate the record. The workflow says it ran and deactivated the record, but it never deactivates).
Anyway. if ANYONE has ANY idea at all about what could be causing this. I would love to hear it. I'm at my wits end on this.
Thank you in advance.
I've tested the code and had it run successfully, as long as I don't update the field through the form. To test this I created some test workflows that update the data, they successfully run and the plugins fire off with no problems.
EntityReference contact =
(EntityReference)preImageEntity.Attributes["ipmahr_contact"];
QueryExpression cn = new QueryExpression("ipmahr_recertification");
cn.ColumnSet = new ColumnSet("ipmahr_contact", "statecode");
cn.Criteria.AddCondition("ipmahr_contact", ConditionOperator.Equal,
contact.Id);
cn.Criteria.AddCondition("statecode", ConditionOperator.Equal, 0);
EntityCollection results1 = server.RetrieveMultiple(cn);
if (results1.Entities.Count > 0)
foreach (Entity a in results1.Entities)
{
a.Attributes["ipmahr_deactivaterecertificationrecord"] = true;
server.Update(a);
}
The code is pretty straightforward in most cases, and works fine as long as things aren't updated on the form.
Here is the error: Exception: System.ServiceModel.FaultException`1[Microsoft.Xrm.Sdk.OrganizationServiceFault]: System.ServiceModel.CommunicationObjectFaultedException: #595EB751 (Fault Detail is equal to Microsoft.Xrm.Sdk.OrganizationServiceFault)., Correlation Id: fd1a79ca-c846-407b-b578-ac9207d6dd0e, Initiating User: 274d55dc-3f4d-e811-b30f-0050569142af Exiting Recertifications.Main.DeactivateUsedRecertificationsonEndDateChange.Execute(), Correlation Id: fd1a79ca-c846-407b-b578-ac9207d6dd0e, Initiating User: 274d55dc-3f4d-e811-b30f-0050569142af
New information. I have found that not all the plugins I've written have an issue on this server. This is good. But I also found that there is a commonality on those plugins that do fail.
Any plugin using a Query Expression fails with the generic error. Adding robust error checking didn't show anything (once error checking was added, it just didn't run anything, and didn't produce any errors in the logs). Trace logs didn't show anything significant either.
So now I'm wondering if there is something in the way the Query Expression is formatted, or if there is an issue with the SQL. I mention SQL because I found this morning that if I create fields too fast, I get a generic SQL error. Wait a minute and I can create new fields without a problem.
I think it likely that this plugin is not actually failing based on the error you are receiving and the fact that it happens conditionally. More likely, your server.Update(a); call is resulting in a failure within a secondary plugin or workflow action triggered by update of the Recertification record.
- Comment out that line and verify that the plugin works
- See if you can reproduce a failure by directly updating that field on the Recertification record
- Review plugin/workflows running against the Recertification entity
Most likely this has one of the following root causes:
- A security issue based on different executing users between the form update or workflow update
- Other tangential fields are being updated by one or the other of those two methods which subsequently cause different behavior in a secondary plugin/workflow
Related
The DialogFlow CX with Page Form Parameters was working well in the test simulator and recently, my chat bots are not responding after user inputs.
When i tried to troubleshoot the issue i realized that the $page.params.status='FINAL' or the $page.params.someparameter.status='UPDATED' events are not firing properly. Due to this the routes are getting failed.
Initially i thought the issue is in my Project. Then i tried the prebuilt agent (travel-baggage claim) in another project. Even that behaves the same without any response after the user inputs are collected.
I also reported this issue to the Developer Advocates in Twitter and updating here as well to get some response from the community.
I’ve tried to replicate your use case but I was able to successfully trigger the condition routes $page.params.status = "FINAL" and $page.params.parameter-name.status = "UPDATED" as expected and transition to the defined page from my end.
See the following for reference:
$page.params.status = "FINAL"
$page.params.parameter-name.status = "UPDATED"
To troubleshoot the issue, you may check if all the conditions defined in your condition route are fulfilled. Also, you may need to check if the condition rules applied is OR or AND. If AND, make sure that all conditions are fulfilled in order to transition to the defined page or flow.
As for the prebuilt agent Travel: baggage claim, I was also able to replicate the same behavior. However, I noticed that this is a different issue since the issue is caused by the webhook being unable to provide a response and not caused by triggering the condition route. I was able to verify this by adding a static response on the condition route and by checking the logs from the simulator. See screenshots below for more information.
Static response
Log snippet from simulator
I tried creating a new flow and migrated all the pages and it works well. I suspect the flow got corrupted when i programmatically tried to update via API.
New to Elixir/Phoenix and GraphQL. I have created a simple API that retrieves "drawings" from a PostgreSQL database. The table consists of an "id" (uuid) and "drawing_json" (text). In the table is one row with a json string of about 77Kb. My schema and queries are defined using Absinthe. I have 1 query called "all_drawings" which resolves and reaches out to the Repo and pulls in all drawings. When using postman to call this API, the following query works fine:
{
allDrawings
{
id
}
}
However, when I try to return the json field as well the postman request times out and I get a "socket hang up" error.
Looking at the Debug Console in Visual Studio Code, I can see the query gets the data from the db just fine and almost immediately. Something seems to be happening though in returning it to the client that I can't detect. No errors are thrown. Any ideas? Not sure what information will help but happy to provide more.
A colleague helped me find the fix. Not sure why this is (maybe someone can elaborate), but the issue was with trying to run it in Visual Studio Code. Previously, I set up the run task in launch.json and would click the run button to start debugging my application. This would cause the aforementioned crash every time. When I went to the terminal and ran the "mix phx.server" command, everything worked fine. Not sure if the hang up is with Visual Studio Code or the ElixirLS extension when using the IDE to debug. But starting the application through the command line allowed me to use postman to hit the api and retrieve the data just fine. I'm very new to the Elixir/Phoenix world so I'm unable to draw a more intelligent conclusion as to why this happens.
I'm building an Expo mobile app using AWS AppSync and Apollo and I've got an intermittent but very serious issue with the cache getting corrupted, or at least not being updated properly. Unfortunately, because I'm using AppSync and I want the offline capability, I can't upgrade to the latest Apollo client, so as a result the data is stored in Redux, there are 4 top-level keys: offline, rehydrated, appsync and appsync-metadata.
This is what I expect to happen:
GraphQL query for a "project" returns the correct data
This data is written into the cache. In particular, I'm expecting that in appsync.ROOT_QUERY there'll be an entry for the project, something like getProject({"input":{"id":"project-7"}}) plus a top level entry in appsync for the project with all of its properties.
When I do execute a mutation, I'm expecting the project entry to be updated.
Since the project is updated, I'm expecting the UI to be refreshed reflecting the updated data.
Most of the time, this happens exactly as above. However, sometimes something happens to the cache. I'm not sure exactly what, but it gets into a weird state and I can't fix it.
Here are the symptoms:
When I start the app, the cache is initialised to an "old" state, one that doesn't include the query for project-7 even though I had queried for it just moments before killing the app.
When I do a search for project-7, it then adds the getProject...project-7 query to the cache and an entry for project-7, but for some reason doesn't seem to have all the fields.
When I do a mutation, there's an AAS_WRITE_CACHE which actually removes the getProject...project-7 entry from the query cache! The mutation succeeds though, I can see that the data in the AppSync server is updated, and the client doesn't log any errors anywhere.
The UI does NOT update.
I tried adding an update to the mutation so that I could update the cache myself, but when I execute const data = proxy.readQuery({ query: ProjectQuery } ... ) (specifying project-7), it throws an exception to say that it can't find that query, so I can't update the project. If I manually re-get the project, then everything works again until the next mutation.
What's really difficult, is that once my app is in this state, I can't work out how to fix it. I've tried client.resetStore() but it just gets rehydrated. I've tried calling AsyncStorage.clear() and then stopping the app and restarting it, but that doesn't work either. How can this be? Where is it storing the data?
It's worth saying again that on most of the devices I've tested it on (both Android and iOS), it works for days without any problems, but on one Android device in particular, it happens once every day or two. Twice I've been able to fix it using the "Clear Async storage" in the React Native Debugger, but now even that doesn't seem to fix it.
So, here are my questions:
Can anyone suggest what might be causing the cache to get into this weird state? Or how I can try and track down the problem.
Where is it storing the data that it then puts back? There are snapshots of the cache in appsync-metadata but surely they should also be removed when I clear all the AsyncStorage?
I'm really stuck!!
PS Here are the relevant (I think) packages I'm using:
"apollo-client": "^2.5.1",
"aws-amplify": "^1.1.27",
"aws-amplify-react-native": "^2.1.11",
"aws-appsync": "^1.7.2",
"aws-appsync-react": "^1.2.7",
"expo": "^33.0.0",
"graphql": "^14.3.0",
"graphql-tag": "^2.10.1",
"react": "16.8.3",
"react-apollo": "^2.5.8",
I've just finished writing a plugin for crm online, and am now running into a curious problem.
When I run the plugin through the debugger I get the expected results, but when I let the plugin run on its own it fails to run as expected.
In this plugin, I'm listening to the create event for new queueitems and I'm checking to see if the queueitm is an email. Everything up to this point is running as expected, however when after getting an email I check to see if the email has an attachment and here's when things start deviating. Through the debugger I can see the attachment file, but on its own, the plugin can't find the attachment. This is very odd to me because I can see the email in the queue and there's definitely an attachment there.
What would cause this to happen, why does it happen and is this a common problem?
Bit of guess.
There is a timing issue, when you debug and that timing issue isn't apparent because you have artificially slowed the application down.
I'm guessing your plugin is sync, and things are happening like this.
In Execution
Email created.
Thread starts to add attachment to email.
Your plugin runs, and finds no attachment.
Thread adds attachment and finishes.
In Debugging
Email created.
Thread starts to add attachment to email.
Your plugin runs, and goes to breakpoint.
Thread adds attachment and finishes.
You inspect the property and find the attachment.
Given that the email and email attachment are separate database tables this seems like a good shout, CRM may be making the two create calls separately.
Ways to test this theory
Make your plugin async.
Add a Thread.Sleep into your code (no more than 2 minutes, a minute should be fine).
Find another place or step to register your plugin.
Stick a plugin on the email attachment create which throws an exception to see what order things happen in.
If my theory turns out to be true, the best resolution is to probably find another way to register your plugin.
I have a new fairly fresh install of Magento 1.7.0.2. I installed two custom payment method modules that are working fine. But now whenever I try to disable or enable any Payment Method or Shipping Method it gives me an error like this:
An error occurred while saving this configuration: Warning:
preg_match() expects parameter 2 to be string, array given in
/app/code/core/Mage/Adminhtml/Model/System/Config/Backend/Encrypted.php
on line 57
Do you have any idea why?
EDIT 2:
I found the problem. It was caused by a patch I applied to fix to a previous BUG. :P
EDIT:
So I disabled all custom modules and I was still getting the same error. I logged what was happening and it seems that some core modules are sending an array to be saved.
Like PayPal Express Checkout for instance. One of the config options is the Time of Day in the SFTP credentials for Settlement Report Settings. It's composed by three different drop-downs and it's sending an array to be saved!
In the Shipping Methods, UPS has a config options called Allowed Methods, and it's also sending an array!
I still don't know why it wasn't happening before and now it is. They shouldn't be encrypting everything. Any clues?
I had the same issue, its a known bug, try this around line no. 135 on code/core/mage/Adminhtml/model/config/data.php
// add this code
$backendClass=false;
if (isset($fieldConfig->backend_model)) {
$backendClass = $fieldConfig->backend_model;
} // before this
if (!$backendClass) {
$backendClass = 'core/config_data';
}
This actually is a reported bug in Magento that seems to affect encrypted config settings (passwords, API keys, etc.).
http://www.magentocommerce.com/bug-tracking/issue?issue=14217
Try disabling the first of the modules, log out of the admin panel, clear /var/cache and see if the problem still exists. If it does, do the same with the second module.
The problem should be gone. Now that you know which module causes the problems you can either decide to try another module instead or debug to see whats going wrong.
Put a breakpoint on line 57 in /app/code/core/Mage/Adminhtml/Model/System/Config/Backend/Encrypted.php to see what goes wrong. It seems that the second parameter is not a string (might be null for example due to wrong configuration or something) when its given to the preg_match function. Maybe this helps you to identify the problem.
Regards
Disabling modules through the back office isn't a good idea as it only disables the block output, if you would like to disable a module you should go to app/etc/modulesand there you should find Module_Name.xmlfile - in this file just put false in active node.