Do you have a custom filter installed? that means the filter it tried to run had an error.

No custom filters installed. This is a very vanilla install of trunk 1026.
Would it make sense to clear the text_filters table in the DB, and then re-run rake migrate?

Is there any way to debug this?

Filter chain halted as [#<Proc:0xb7c33294@/..../public/../config/../vendor/rails/actionpack/lib/action_controller/filters.rb:226>] returned false

Ok, reading more carefully that's actually not a textfilter, that's a controller's before filter. Hrm. I don't know what would cause that, or what the problem is. Sorry.

Can you check and see if the latest revision (r1029) fixes this?

I just tested r1029 and the filter chain output is still cropping up. Does the fix work for anyone else?

tested revision 1029 but the problem still remains :-(

I have the same problem, any ideas? Updating didn't work (currently at revision 1039).

This might have something to do with Raisl 1.0 and 1.1 incompatibilities, since my blog is hosted on Site5, and they still use 1.0 as far as I know. I noticed that Typo from svn is becoming more and more unstable (in constrast to before), so I was wondering if it's possible to migrate back to 2.6.0, just until 4.0 is out?

Uhhh, yeah. Typo trunk doesn't work with Rails 1.0. If you're using svn, though, it should automatically check Rails 1.1.2 out into the vendor directory, so it should be using that. If you're using some other tool (like, for example, svk) to get Typo trunk, then you should check out Rails 1.1.2 to the vendor/rails directory yourself.

It gets checked out in the vendor directory, and it should use that as well. But maybe there's another incompatibility at Site5 somewhere (don't know). Does anyone know how to resolve the filter problem?

Running Typo on site5 and getting filter chain halted error as well. Restarting fastcgi with "killall -9 dispatch.fcgi" fixes it for me temporarily, but it inevitably comes back.

I am getting the same thing and came across this post
http://lists.rubyonrails.org/pipermail/rails/2006-May/044223.html

sounds like it could be a rails 1.8.2 vs 1.8.4 problem

Is this still happening with the most recent trunk? If you're still seeing it, can you report:

1. Your Ruby version
2. Your Rails version
3. Your DB
4. Production or development mode
5. Which theme?

ruby 1.8.4 (2005-12-24) [i386-solaris2.8]
Rails 1.1.2
mysql Ver 14.12 Distrib 5.0.22, for pc-solaris2.8 (i386) using readline 5.0
Production
Lush

We have apache2 server with mongrel running rails.

Took me a while but I finally figured this out. This is an existing problem with rails because it implements action caching as a filter. When you hit the cache, it serves the cached copy and exits the filter. As all filters that are exited are logged, this happens on every cache hit. I tried it with caches_action in rails and verified that it also spits out this error. I wish there were some way to skip this logging on cache hits but I don't see one.

I don't see any way around this. Any time a filter exits 'false', it logs an error and aborts the filter chain. Except that's what the action cache is supposed to do. It has to abort the filter chain on a cache hit, or it's not actually a cache :-).

I don't see any way to avoid the warning short of setting and resetting 'logger' with the cache, but I don't see how we'd reset it after returning false.

Since this is ONLY a log issue, not a visible problem, I'm going to call it 'wontfix'. Feel free to reopen if you have a fix.