Can we somehow achieve or build a canister with a interface bahaving like a classic web server

Developers
#21

Because I need to increase the timeout, I can’t use your implementation at ic.nomeata.de.

Which timeout do you need? I can change my setup if you want. But maybe better to let you host your own :slight_smile:

I do see “Provide your own bootstrap on Amazon Linux 2”, which I assume is what you must have done to get this to run.

I think so, yes. It says “Custom runtime on Amazon Linux 2” here. (Not an AWS expert myself.)

Will I need to make changes to (patch?) the runtime code (agent-rs?) to get it to work the way you did?

Nope, if you look at my Cargo.toml you’ll see that it pins the patched version of the agent:

[patch.crates-io]
ic-agent = { git = "https://github.com/nomeata/agent-rs", branch = "joachim/musl-hacks" }
ic-types = { git = "https://github.com/nomeata/agent-rs", branch = "joachim/musl-hacks" }
#22

@nomeata I tried putting together a PR for the increased timeout, but I can’t get ic-http-bridge to run locally anymore, even without the change. When I try to make a request to http://127.0.0.1:7878/, it causes the local dfx server to crash, which then restarts with a new port number, and ic-http-bridge respond with Could not reach the server presumably because it’s looking on the old port. Relaunching ic-http-bridge with dfx’s new port just repeats the cycle and I never get a response.

This is the crash reported by the process started with dfx start:
thread 'Http Handler' panicked at 'Opening old round db failed 493301', src/cow_state/slot_mgr.rs:469:37

#23

In any case, when I was able to get this running, the timeout I needed to increase was on line 164:

let result = if result.upgrade {
    // Re-do the request as an update call
    agent.fetch_root_key().await?;
    let waiter = delay::Delay::builder()
        .throttle(std::time::Duration::from_millis(500))
        .timeout(std::time::Duration::from_secs(90))    // <-- increased from 5 to 90
        .build();

90 seconds is definitely more than I need; I was just using that for testing. I recall responses coming back in around 30-40 seconds.

1 Like
#24

EDIT: did you try using the dfx start --clean command yet?

1 Like
#25

Which command? I’m not seeing --clean as a flag on any of the dfx commands. In the past, I’ve cleaned by deleting the .dfx folder, but doing that and then rebuilding results in the same cid for my canisters, so there must be something else that’s not getting cleaned up.

edit: Not sure how I missed dfx start ~~clean but things are working now
edit edit: those tildes are supposed to be dashes, but editing a post on this forum causes a 403 error if it includes dashes…

1 Like
#26

Can we implement Telegram bot all by canisters in the future?

#27

Sure, why not? (Assuming you use a HTTP bridge like the one I built, or eventually building on something similar that makes it into the offical offering.)

2 Likes
#28

Hey, I’m new here (and newbie programmer overall), came from Python that I fell in love, now Dfinity is my new romance, but I need to make a big jump :D.

I like writing telegram bots in python, so doing one on IC seems to be perfect example to start with.

Questions:

  • Whole bot logic is pure rust, and I can change in without problems?
  • Bot is connected to ic-http-lambda running on AMAZON LAMBDA service? Is this like webhook and bridge between old rusty internet and new shiny IC? : D
  • Live demo is pointing to your local environment? Or it’s live on IC and cost cycles?
  • Can I write something to fetch data from outside http APIs and save it to IC, or forward to telegram chat?

Sorry for stupid question if asked, but the whole thing is still shaping in my head :slight_smile:
Thanks for help, and great job!

1 Like