I'm using a Sentinel policy inside a Terraform Cloud workspace. My policy is rather simple:
import "tfplan/v2" as tfplan
allBDs = tfplan.find_resources("aci_bridge_domain")
violatingBDs = tfplan.filter_attribute_does_not_match_regex(allBDs,
"description", "^demo(.+)", true)
main = rule {
length(violatingBDs["messages"]) is 0
}
Unfortunately, it fails when invoked with this message:
An error occurred: 1 error occurred:
* ./allowed-terraform-version.sentinel:3:10: key "find_resources" doesn't support function calls
The documentation and source for find_resources (doc) expects a string, yet the Sentinel interpreter seems to think I'm invoking a method of tfplan? It's quite unclear why that is, and the documentation doesn't really help.
Any ideas?
OK I found the issue. If I paste the code for find_resources and its dependencies (to_string, evaluate_attribute) then everything works as expected.
So I have a simple import problem and need to figure out how to properly import https://raw.githubusercontent.com/hashicorp/terraform-guides/master/governance/third-generation/common-functions/tfplan-functions/tfplan-functions.sentinel
Related
I'm using Webpack Module Federation to create 2 React applications: host and child.
In the host, I create atoms.ts and selector.ts filed and I expose them via the plugin under the expose section:
exposes: {
"./atoms": "./src/recoil/atoms.ts",
"./selectors": "./src/recoil/selectors.ts",
}
Inside the child, I just consume that via the remotes section:
remotes: {
host: "host#http://localhost:3000/remoteEntry.js",
}
Then, in the code of the child I use that like that:
import {someSelector} from "host/selectors"
const val = useRecoilValue(someSelector);
It's working fine but I got this warning in the console:
Duplicate atom key "userAuthState". This is a FATAL ERROR in
production. But it is safe to ignore this warning if it occurred because of
hot module replacement.
Does anyone face that issue and know if it's really a problem or how we could hide the warning?
Another related q:
Is it ok that the host will contain <RecoilRoot> and also the child will contain <RecoilRoot> ? because I want both will manage their own state but also share atom/selectors.
Thanks!
Regarding your second question:
Yes, this is totally fine. The nested <RecoilRoot> will create its own context and every atom referenced below the second root will be independent from the upper root. This is also explained in the docs.
Regarding the first question: As the log states this is fine as long as it occurs during development. Sometimes during the hot module replacement recoil throws away atoms and reinstantiates them causing this duplication to happen internally.
But as long as this warning doesn't pop up in your production code, everything is fine.
Are you importing the atoms or the selectors in your host application using a local path?
You need to include in your host webpack config its own entrypoint as remote and import your atoms from 'host/atoms'
I think this could solve your issue.
You can ignore the warning output (if you can bare it), functionality is not affected.
Also, you can install the intercept-stdout package and add the following to next.config.js (outside of the exported configuration):
const intercept = require("intercept-stdout")
// safely ignore recoil warning messages in dev (triggered by HMR)
function interceptStdout(text) {
if (text.includes("Duplicate atom key")) {
return "";
}
return text;
}
if (process.env.NODE_ENV === "development") {
intercept(interceptStdout);
}
This way can omit the annoying warning in console.
=== SAD PANDA ===
TypeError: Failed to fetch
=== SAD PANDA ===
While executing a flow cadence transaction in react.js, I got the above error.
My intention is when I click the minttoken button, this transaction has to execute so as to mint the NFT.
const mintToken = async() => {
console.log(form.name)
const encoded = await fcl.send([
fcl.proposer(fcl.currentUser().authorization),
fcl.payer(fcl.authz),
fcl.authorizations([fcl.authz]),
fcl.limit(50),
fcl.args([
fcl.arg(form.name,t.String),
fcl.arg(form.velocity,t.String),
fcl.arg(form.angle,t.String),
fcl.arg(form.rating,t.String),
fcl.arg(form.uri,t.String)
]),
fcl.transaction`
import commitContract from 0xf8d6e0586b0a20c7
transaction {
let receiverRef: &{commitContract.NFTReceiver}
let minterRef: &commitContract.NFTMinter
prepare(acct: AuthAccount) {
self.receiverRef = acct.getCapability<&{commitContract.NFTReceiver}>(/public/NFTReceiver)
.borrow()
?? panic("Could not borrow receiver reference")
self.minterRef = acct.borrow<&commitContract.NFTMinter>(from: /storage/NFTMinter)
?? panic("could not borrow minter reference")
}
execute {
let metadata : {String : String} = {
"name": name,
"swing_velocity": velocity,
"swing_angle": angle,
"rating": rating,
"uri": uri
}
let newNFT <- self.minterRef.mintNFT()
self.receiverRef.deposit(token: <-newNFT, metadata: metadata)
log("NFT Minted and deposited to Account 2's Collection")
}
}
`
]);
await fcl.decode(encoded);
}
this error being so useless is my fault, but I can explain what is happening here because it also only happens in a really specific situation.
Sad Panda error is a catch all error that happens when there is a catastrophic failure when fcl tries to resolve the signatures and it fails in a completely unexpected way. At the time of writing this it usually shows up when people are writing their own authorization functions so that was the first thing i looked at in your code example. Since you are using fcl.authz and fcl.currentUser().authorization (both of those are the same by the way) your situation here isnt because of a custom authorization function, which leads me to believe this is either a configuration issue (fcl.authz is having a hard time doing its job correctly) or what fcl is getting back from the wallet doesn't line up with what it is expecting internally (most likely because of an out of date version of fcl).
I have also seen this come up when the version of the sdk that fcl uses doesnt line up with the version of the sdk that is there (because some people have added #onflow/sdk as well as #onflow/fcl) so would also maybe check to make sure you only have fcl in your package.json and not the sdk as well (everything you should need from the sdk should be exposed from fcl directly, meaning you shouldnt need the sdk as a direct dependency of your application)
I would first recommend making sure you are using the latest version of fcl (your code should still all work), then i would make sure you are only using fcl and not inadvertently using an older version of the sdk. If you are still getting the same error after that could you create an issue on the github so we can dedicate some resources to helping sort this out (and make it so you and others dont see this cryptic error in future versions of fcl)
I am wondering why this code shows an error saying that it expects a ChainBuilder but found B, and what B actually is. I'm a few months now wondering about this issue since my code still compiles with it but I would love to remove this error if possible.
Even when I simplify it the most but keeping the exitBlockOnFail piece it will still give me the red warning, so I'd like to know what is the connection between the two of them please.
// Error
object StudentDashboardBranches {
def studentDashboard: ChainBuilder = exitBlockOnFail(
exec {
session =>
println(session("session").as[String])
session
}
)
}
// No error
object StudentDashboardBranches {
def studentDashboard: ChainBuilder = (
exec {
session =>
println(session("session").as[String])
session
}
)
}
And perhaps a different question or maybe related to the same issue, not sure, but the exec method appended after the pause is not recognised, however, this error doesn't leave if I delete the exitBlockOnFail piece as the first one does.
PS: These are my imports
import io.gatling.core.Predef.{exec, _}
import io.gatling.core.structure.ChainBuilder
Any help or clarification is much appreciated.
Many thanks.
UPDATE
As per Stephane's answer, we were missing one of the imports.
import io.gatling.core.Predef._ // required for Gatling core structure DSL
It's working now.
Have you broken the DSL imports? If so, please check the doc.
I have a method in a gatling user-script as below.
This script was written in gatling 2.3.
def registerAddress: ChainBuilder = {
exec(ws("WS Register Address").wsName(id)
.sendText(prefetchAddress)
.check(wsAwait.within(30).until(1).regex("success").exists))
.exec(ping)
}
I am converting this in to gatling 3.0 and when I try to run it I get the following error.
value check is not a member of io.gatling.http.action.ws.WsSendTextFrameBuilder
I searched everywhere but I couldn't find a documentation related to WsSendTextFrameBuilder class to change the method call accordingly.
Does anyone know a documentation related to this class or a way to fix this issue?
Thank you.
After going through the documentation of Gatling 2.3 and 3.0 I found the new calls for the above scenario.
Apparently the check method is not available anymore in the WsSendTextFrameBuilder class.
Instead of that should use the await method.
So the code would look something similar to below.
val checkReply = ws.checkTextMessage("request").check(regex("request-complete"))
def registerAddress: ChainBuilder = {
exec(ws("WS Register Address").wsName(id)
.sendText(prefetchAddress)
.await(30 seconds)(checkReply))
.exec(ping)
}
Is it possible to get info on what instance you're running on? I want to output just a simple identifier for which instance the code is currently running on for logging purposes.
Since there is no language tag, and seeing your profile history, I assume you are using GAE/J?
In that case, the instance ID information is embedded in one of the environment attributes that you could get via ApiProxy.getCurrentEnvironment() method. You could then extract the instance id from the resulting map using key BackendService.INSTANCE_ID_ENV_ATTRIBUTE.
Even though the key is stored in BackendService, this approach will also work for frontend instances. So in summary, the following code would fetch the instance ID for you:
String tInstanceId = ApiProxy.getCurrentEnvironment()
.getAttributes()
.get( BackendService.INSTANCE_ID_ENV_ATTRIBUTE )
.toString();
Please keep in mind that this approach is quite undocumented by Google, and might subject to change without warning in the future. But since your use case is only for logging, I think it would be sufficient for now.
With the advent of Modules, you can get the current instance id in a more elegant way:
ModulesServiceFactory.getModulesService().getCurrentInstanceId()
Even better, you should wrap the call in a try catch so that it will work correctly locally too.
Import this
import com.google.appengine.api.modules.ModulesException;
import com.google.appengine.api.modules.ModulesServiceFactory;
Then your method can run this
String instanceId = "unknown";
try{
instanceId = ModulesServiceFactory.getModulesService().getCurrentInstanceId();
} catch (ModulesException e){
instanceId = e.getMessage();
}
Without the try catch, you will get some nasty errors when running locally.
I have found this super useful for debugging when using endpoints mixed with pub-sub and other bits to try to determine why some things work differently and to determine if it is related to new instances.
Not sure about before, but today in 2021 the system environment variable GAE_INSTANCE appears to contain the instance id:
instanceId = System.getenv("GAE_INSTANCE")