I have an API in WSO2. When I try to test it in the store with valid parameters via GET, it returns the following error message:
<am:fault xmlns:am="http://wso2.org/apimanager">
<am:code>101504</am:code>
<am:type>Status report</am:type>
<am:message>Runtime Error</am:message>
<am:description>Send timeout</am:description>
</am:fault>
I have already searched and tried a lot, but with no success, always returning the same error. Don't know if helps, but the api that I try to access is a PHP file.
Any ideas?
EDIT:
I have identical apis to this one, changing only the response, that are working properly. Even if I erase the php file that the API is pointing, the error keep coming.
EDIT:
I changed the code in Management Console, in Metadata>List>APIs:
{"production_endpoints":
{"url":"http://site/myapi.php","config":
{"format":"leave-as-is","optimize":"leave-as-
is","actionSelect":"fault","actionDuration":30000}},
"sandbox_endpoints":
{"url":"http://site/myapi.php","config":
{"format":"leave-as-is","optimize":"leave-as-
is","actionSelect":"fault","actionDuration":30000}},
"implementation_status":"managed","endpoint_type":"http"}
to this:
{"production_endpoints":
{"url":"http://10.20.40.189/ConsultaAutorizacaoCadPos.php","config":null},
"sandbox_endpoints":{"url":"http://10.20.40.189/ConsultaAutorizacaoCadPos.php","config":null},
"implementation_status":"managed","endpoint_type":"http"}
And this error message vanishes. But this new one appears:
<am:fault xmlns:am="http://wso2.org/apimanager">
<am:code>303001</am:code>
<am:type>Status report</am:type>
<am:message>Runtime Error</am:message>
<am:description>Currently , Address endpoint : [ Name : admin--myapi_APIproductionEndpoint_0 ] [ State : SUSPENDED ]</am:description>
EDIT: this error message is appearing just sometimes. Most of the time the request takes long time to run and then returns nothing( no content )
Any ideas how to solve it?
Related
We are trying to replicate data from AlloyDB to Bigquery using Datastream.
We Get "An unknown error occurred. Please try again. If the error persists, contact Google support."
In the Datastream console --> objects list, we see all source tables with Object Status "Failed" and Backfill status "Completed".
In Bigquery we see only a subset of the tables (not all the "Completed" objects were synced).
In the Logs Explorer I can see this error on BQ:
I also see this error: error: {
code: 11
message: "Unsupported primary key column either does not exist or is a pseudocolumn at [1:401]"
}
The column referred in the error is of type enum.
The desired situation is having all the AlloyDB tables replicated into Bigquery.
The error message is not very informative...
What does it mean?
What would be the best way to go about troubleshooting this?
We're actively working on making these error messages be more informative, and improvements are continuously being rolled out as we identify more edge cases. Assuming you followed all the steps in the documentation, then you may need to open a ticket with support for further investigation. If a support ticket isn't an option, you can still report the issue using the public issue tracker
I just had this same issue but connecting to a PostgreSQL in AWS RDS:
Beginning with Postgres 10, passwords are encrypted using SCRAM-SHA-256 in PostgreSQL. Google DataStream still expects MD5 password encryption, or it will generate an "unknown error" in the logs and fail the backfills.
You'll need to update your postgresql.conf (or RDS Cluster Parameter Group if you're using AWS like me):
password_encryption = 'MD5'
Restart the database and make sure the parameter has changed with:
SHOW password_encryption;
Reset the password of your users:
ALTER USER "{username}" with password '{password}';
More info from the PostgreSQL docs: https://www.postgresql.org/docs/current/auth-password.html
When attempting to make a call to a program compiled with #solana/solidity, I'm getting the following error:
Transaction simulation failed: Error processing Instruction 0: Program failed to complete
Program jdN1wZjg5P4xi718DG2HraGuxVx1mM7ebjXpxbJ5R3N invoke [1]
Program log: pxKTQePwHC9MiR52J5AYaRtSLAtkVfcoGS3GaLD24YX
Program log: sender account missing from transaction
Program jdN1wZjg5P4xi718DG2HraGuxVx1mM7ebjXpxbJ5R3N consumed 200000 of 200000 compute units
Program failed to complete: BPF program Panicked in solana.c at 285:0
Program jdN1wZjg5P4xi718DG2HraGuxVx1mM7ebjXpxbJ5R3N failed: Program failed to complete
jdN1wZjg5P4xi718DG2HraGuxVx1mM7ebjXpxbJ5R3N is the program's public key and pxKTQePwHC9MiR52J5AYaRtSLAtkVfcoGS3GaLD24YX is the sender's public key.
I'm using a fork of the #solana/solidity library that exposes the Transaction object so that it can be signed and sent by Phantom Wallet on the front end. The code that results in the error is as follows:
// Generate the transaction
const transaction = contract.transactions.send(...args);
// Add recent blockhash and fee payer
const recentBlockhash = (await connection.getRecentBlockhash()).blockhash;
transaction.recentBlockhash = recentBlockhash;
transaction.feePayer = provider.publicKey;
// Sign and send the transaction (throws an error)
const res = await provider.signAndSendTransaction(transaction);
I would attempt to debug this further myself, but I'm not sure where to start. Looking up the error message hasn't yielded any results and the error message isn't very descriptive. I'm not sure if this error is occurring within the program execution itself or if it's an issue with the composition of the transaction object. If it is an issue within the program execution, is there a way for me to add logs to my solidity code? If it's an issue with the transaction object, what could be missing? How can I better debug issues like this?
Thank you for any help.
Edit: I'm getting a different error now, although I haven't changed any of the provided code. The error message is now the following:
Phantom - RPC Error: Transaction creation failed. {code: -32003, message: 'Transaction creation failed.'}
Unfortunately this error message is even less helpful than the last one. I'm not sure if Phantom Wallet was updated or if a project dependency was updated at some point, but given the vague nature of both of these error messages and the fact that none of my code has changed, I believe they're being caused by the same issue. Again, any help or debugging tips are appreciated.
I was able to solve this issue, and although I've run into another issue it's not related to the contents of this question so I'll post it separately.
Regarding my edit, I found that the difference between the error messages came down to how I was sending the transaction. At first, I tried sending it with Phantom's .signAndSendTransaction() method, which yielded the second error message (listed under my edit). Then I tried signing & sending the transaction manually, like so:
const signed = await provider.request({
method: 'signTransaction',
params: {
message: bs58.encode(transaction.serializeMessage()),
},
});
const signature = bs58.decode(signed.signature);
transaction.addSignature(provider.publicKey, signature);
await connection.sendRawTransaction(transaction.serialize())
Which yielded the more verbose error included in my original post. That error message did turn out to be helpful once I realized what to look for -- the sending account's public key was missing from the keys field on the TransactionInstruction on the Transaction. I added it in my fork of the #solana/solidity library and the error went away.
In short, the way I was able to debug this was by
Using provider.request({ method: 'signTransaction' }) and connection.sendRawTransaction(transaction) rather than Phantom's provider.signAndSendTransaction() method for a more verbose error message
Logging the transaction object and inspecting the instructions closely
I hope this helps someone else in the future.
I am trying to build a simple asynchronous web service with Apache and mod_perl. But every time I try to return HTTP status 202 (Accepted), I get an error.
Below a very simple example (non-asynchronous):
package MyHandler;
use Apache2::Const '-compile' => qw 'OK HTTP_ACCEPTED HTTP_OK';
use Apache2::RequestRec;
use CGI;
sub handler {
my $r = shift;
print "Hallo";
$r->content_type('text/plain');
$r->status(Apache2::Const::HTTP_ACCEPTED);
return Apache2::Const::HTTP_ACCEPTED;
}
1;
I get the error
calling the handler in my browser on localhost, I get the output but also an error:
Hallo
Accepted
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, [no address given] and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
I also get an error with Apache2::Const::HTTP_OK, the only one that works without error is Apache2::Const::OK.
My apache error log makes no mention of this error.
With mod_perl2 you do not return HTTP status codes (this is why it is necessary to use $r->status() so set the HTTP status code.
Instead, you return a value depending on what you want the server to do. The most common would be Apache2::Const::OK. This tells the server your handler has finished successfully. This constant, if I recall correctly, has an integer value of 0, not 200.
Returning an HTTP status code from a mod_perl handler will be interpreted as an error.
https://perl.apache.org/docs/2.0/user/handlers/intro.html#Handler_Return_Values
Different handler groups are supposed to return different values.
Make sure that you always explicitly return a wanted value and don't rely on the result of last expression to be used as the return value -- things will change in the future and you won't know why things aren't working anymore.
The only value that can be returned by all handlers is Apache2::Const::OK, which tells Apache that the handler has successfully finished its execution.
Apache2::Const::DECLINED is another return value that indicates success, but it's only relevant for phases of type RUN_FIRST.
HTTP handlers may also return Apache2::Const::DONE which tells Apache to stop the normal HTTP request cycle and fast forward to the PerlLogHandler, followed by PerlCleanupHandler. HTTP handlers may return any HTTP status, which similarly to Apache2::Const::DONE will cause an abort of the request cycle, by also will be interpreted as an error. Therefore you don't want to return Apache2::Const::HTTP_OK from your HTTP response handler, but Apache2::Const::OK and Apache will send the 200 OK status by itself.
Try NOT printing anything BEFORE you set your content-type header.
Streaming data into BigQuery keeps failing due to the following error, which occurs more frequently recently:
com.google.api.client.googleapis.json.GoogleJsonResponseException: 503 Service Unavailable
{
"code" : 503,
"errors" : [ {
"domain" : "global",
"message" : "Connection error. Please try again.",
"reason" : "backendError"
} ],
"message" : "Connection error. Please try again."
}
at com.google.api.client.googleapis.json.GoogleJsonResponseException.from(GoogleJsonResponseException.java:145)
at com.google.api.client.googleapis.services.json.AbstractGoogleJsonClientRequest.newExceptionOnError(AbstractGoogleJsonClientRequest.java:113)
at com.google.api.client.googleapis.services.json.AbstractGoogleJsonClientRequest.newExceptionOnError(AbstractGoogleJsonClientRequest.java:40)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest$1.interceptResponse(AbstractGoogleClientRequest.java:312)
at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:1049)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:410)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:343)
Relevant question references:
Getting high rate of 503 errors with BigQuery Streaming API
BigQuery - BackEnd error when loading from JAVA API
We (the BigQuery team) are looking into your report of increased connection errors. From the internal monitoring, there hasn't been global a spike in connection errors in the last several days. However, that doesn't mean that your tables, specifically, weren't affected.
Connection errors can be tricky to chase down, because they can be caused by errors before they get to the BigQuery servers or after they leave. The more information your can provide, the easier it is for us to diagnose the issue.
The best practice for streaming input is to handle temporary errors like this to retry the request. It can be a little tricky, since when you get a connection error you don't actually know whether the insert succeeded. If you include a unique insertId with your data (see the documentation here), you can safely resend the request (within the deduplication window period, which I think is 15 minutes) without worrying that the same row will get added multiple times.
I try to get information from Yodlee API.
I have a test user where I've implemented adding an account and I got refresh OK from the site:
{ siteRefreshStatus: {
siteRefreshStatusId: 8
siteRefreshStatus: "REFRESH_COMPLETED_WITH_UNCERTAIN_ACCOUNT"
}
- siteRefreshMode: {
refreshModeId: 2
refreshMode: "NORMAL"
}
- updateInitTime: 0
nextUpdate: 1391603301
code: 403
noOfRetry: 0
}
}
Now when I try to perform search and get the actual transactions I get this error:
{
errorOccured: "true"
exceptionType: "com.yodlee.core.IllegalArgumentValueException"
refrenceCode: "_57c250a9-71e8-4d4b-830d-0f51a4811516"
message: "Invalid argument value: Container type cannot be null"
}
The problem is that I have container type!
Check out the parameters I send:
cobSessionToken=08062013_2%3Ad02590d4474591e507129bf6baaa58e81cd9eaacb5753e9441cd0b1ca3b8bd00a3e6b6a943956e947458307c1bb94b505e2eb4398f890040a3db8c98606c0392&userSessionToken=08062013_0%3A8e8ef9dd4f294e0f16dedf98c1794b96bf33f2e1f2686eda2f35dfe4901dd3a871eed6d08ce52c99a74deb004c025ebf4bf94c7b17baf8ba18aacb331588f5f5&transactionSearchRequest.containerType=bank&transactionSearchRequest.higherFetchLimit=1000&transactionSearchRequest.lowerFetchLimit=1&transactionSearchRequest.resultRange.endNumber=500&transactionSearchRequest.resultRange.startNumber=1&transactionSearchRequest.searchClients.clientId=1&transactionSearchRequest.searchClients.clientName=DataSearchService&transactionSearchRequest.ignoreUserInput=true&transactionSearchRequest.searchFilter.currencyCode=USD&transactionSearchRequest.searchFilter.postDateRange.fromDate=01-01-2014&transactionSearchRequest.searchFilter.postDateRange.toDate=01-31-2014&transactionSearchRequest.searchFilter+.transactionSplitType=ALL_TRANSACTION&transactionSearchRequest.searchFilter.itemAccountId+.identifier=10008425&transactionSearchRequest.searchClients=DEFAULT_SERVICE_CLIENT
There is an error occurred while adding the account, which can be interpreted by this parameter code: 403 and hence you will not be seeing that account when you call the getItemSummary API. An account is successfully linked if the code has zero as value. E.g.code:0 . 403 is an error which is show if Yodlee's data agent has encountered an unhandled use case. Hence for any such error you should file a service request using Yodlee customer care tool.
To know more about error codes please visit -
https://developer.yodlee.com/FAQs/Error_Codes
The status is show as completedsiteRefreshStatus: "REFRESH_COMPLETED_WITH_UNCERTAIN_ACCOUNT"because addition of any account is followed by a refresh in which Yodlee's data agent logs into the websites of FIs and try scraping data. Hence completion of this activity is denoted as REFRESH_COMPLETED even when there is an error occurred.
TranasctionSearch issue -
I can see two of the parameters with a "+" sign. Since transactionSlipttype and containerType are dependent on each other the error is thrown.
&transactionSearchRequest.searchFilter+.transactionSplitType=ALL_TRANSACTION
&transactionSearchRequest.searchFilter.itemAccountId+.identifier=10008425
The right parameters are -
&transactionSearchRequest.searchFilter.transactionSplitType=ALL_TRANSACTION
&transactionSearchRequest.searchFilter.itemAccountId.identifier=10008425